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ABSTRACT 

The  US  military  requires  a  reliable,  high-speed,  multimedia  capable  system  to 
disseminate  information  that  cannot  be  efficiently  distributed  over  existing  low  data  rate 
channels.  The  Global  Broadcast  Service  (GBS)  is  being  developed  to  meet  this 
requirement.  The  cornerstones  of  the  GBS  simplex  broadcast  are  the  premises  of  smart 
push  and  user  pull.  An  integral  part  of  the  user  pull  is  the  reach  back  channel.  The  reach 
back  channel  allows  users  to  specify  the  information  they  need  broadcast  and  tailor  the 
information  to  meet  their  mission  needs.  Ultra  high  frequency  (UHF)  demand  assigned 
multiple  access  (DAMA)  satellite  communications  are  the  most  widely  available  long 
haul  communication  systems  available  to  members  of  the  armed  services  and  as  such  are 
a  prime  candidate  to  provide  a  reach  back  path  for  GBS.  In  order  to  fully  utilize  UHF 
DAMA  as  a  reach  back  channel  for  data  communications  a  number  of  interface 
requirements  must  be  met.  The  problems  of  using  UHF  DAMA  are  discussed  and 
recommendations  are  made  for  the  GBS  Phase  Two  systems  so  they  might  support  the 
use  of  UHF  DAMA  as  a  reach  back  channel.  This  thesis  shows  that  UHF  DAMA  is  a 
viable  reach  back  channel,  however  there  are  factors  which  could  improve  the  efficiency. 
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EXECUTIVE  SUMMARY 

The  US  military  requires  a  reliable,  high-speed,  multimedia  capable  system  to 
disseminate  information  that  cannot  be  efficiently  distributed  over  existing  low  data  rate 
channels.  The  Global  Broadcast  Service  (GBS)  is  being  developed  to  meet  this 
requirement.  The  GBS  program  is  capitalizing  on  the  huge  civilian  investment  in  direct 
broadcast  satellite  (DBS)  technology  and  adapting  it  to  meet  warfighter  needs.  DBS 
technology  offers  small  end-user  antennas,  increased  mobility,  and  an  aggregate  data  rate 
of  up  to  23  million  bits  per  second. 

The  GBS  program  is  being  developed  in  three  phases.  Phase  one  involves  the 
lease  of  commercial  Ku-band  transponders  and  the  use  of  commercial  off  the  shelf 
(COTS)  components.  Although  Phase  One  has  been  used  primarily  for  testing  and 
exercises,  it  has  also  supported  the  delivery  of  information  to  North  Atlantic  Treaty 
Organization  (NATO)  peacekeeping  forces  in  Bosnia.  Phase  two  is  an  initial  military 
capability  with  GBS  Ka-band  transponders  hosted  on  the  Ultra  High  Frequency  (UHF) 
Follow  On  (UFO)  Satellites  8,  9,  and  10.  UFO  8  was  launched  in  Spring  1998  and  the 
first  receive  suites  will  be  delivered  in  late  summer  1998.  Phase  three,  scheduled  to  begin 
in  2009,  is  the  complete  integration  of  GBS  into  the  Defense  Information  Infrastructure. 
This  thesis  concentrates  on  the  GBS  Phase  One  and  Phase  Two  systems. 

The  cornerstones  of  the  GBS  program  are  the  concepts  of  smart  push  and  user 
pull.  The  information  content  of  the  smart  push  is  determined  at  the  theater  level  without 
real-time  input  from  end-users  at  the  unit  level.   User  pull  allows  unit  level  end-users  to 

xi 


define  specific  information  to  be  broadcast  on  demand  in  response  to  operational 
circumstances.  User  pull  also  enables  end-users  to  request  that  certain  smart  push 
products  be  rebroadcast  in  the  event  that  they  were  not  received  at  their  unit  during  the 
regularly  scheduled  smart  push.  Both  these  capabilities  are  enabled  by  the  reach  back 
channel.  The  reach  back  channel  can  be  implemented  with  any  suitable  means  of 
communication  available  to  the  unit  level  force  in  question. 

UHF  demand  assigned  multiple  access  (DAMA)  satellite  communications  is  the 
most  widely  available  long  haul  system  to  members  of  the  armed  services.  As  such,  it  is 
a  prime  candidate  to  provide  a  reach  back  path  for  GBS.  In  order  to  fully  utilize  UHF 
DAMA  as  a  reach  back  channel  for  user  pull  communications,  a  number  of  interface 
requirements  must  be  met.  One  of  the  problems  encountered  when  using  UHF  DAMA  as 
a  GBS  reach  back  channel  is  the  substantial  time  delay  associated  with  the  DAMA 
protocol  itself.  In  fact,  UHF  DAMA  may  represent  a  worst  case  scenario  for  timing 
delays.  Modern  day  computer  communication  protocols  such  as  the  ubiquitous 
Transmission  Control  Protocol  /  Internet  Protocol  (TCP/IP)  do  not  tolerate  long 
communications  delays  well.  A  number  of  systems  have  been  developed  to  interface 
protocols  such  as  TCP/IP  with  UHF  DAMA.  An  example  is  the  Automated  Digital 
Network  System  (ADNS),  a  major  portion  of  the  Navy's  Joint  Maritime  Communications 
Strategy  (JMCOMS).  ADNS  has  developed  protocols  to  interface  computer 
communications  with  a  large  number  of  transmission  media,  including  UHF  DAMA.    It 
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is  the  performance  of  just  such  an  interface,  the  UHF  DAMA  channel  access  protocol 
(CAP),  which  is  investigated  in  this  thesis. 

The  Naval  Postgraduate  School  (NPS)  has  developed  a  GBS  Phase  One  test  bed 
with  some  unique  testing  capabilities.  In  addition,  the  ADNS  program  office  has 
established  a  lab  for  testing  of  the  ADNS  CAPs  at  the  Space  and  Naval  Warfare  Systems 
Center  in  San  Diego  (SSC-SD).  The  NPS  test  bed  and  the  ADNS  lab  were  connected 
using  an  IP  tunnel  through  the  Secure  Internet  Protocol  Routed  Network  (SIPRNET). 
The  tunnel  established  a  virtual  connection  between  the  two  labs  and  allowed  testing 
using  UHF  DAMA  SATCOM  assets  at  SSC-SD  as  the  reach  back  channel  for  the  GBS 
receiver  suite  at  NPS.  The  tests  were  conducted  using  the  manual  retransmit  request  on 
the  GBS  Phase  One  software  and  varying  the  loading  on  the  UHF  DAMA  back  channel. 
The  manual  retransmit  request  consists  of  a  short  (~  200  bytes)  TCP/IP  connection 
between  the  NPS  test  bed  and  the  Phase  One  GBS  satellite  uplink  facility.  If  the 
requested  files  were  available  at  the  GBS  uplink  facility,  then  they  were  queued  up  and 
delivered  over  the  Phase  One  GBS  CONUS  broadcast.  If  the  files  were  not  available, 
then  the  request  failed.  Parameters  such  as  the  number  of  users  and  the  traffic  load  were 
varied  on  the  UHF  DAMA  back  channel  until  the  computer  communications  failed. 

The  results  of  this  testing  have  identified  some  areas  of  concern  for  GBS  Phase 
Two.  However,  it  is  early  enough  that  if  these  concerns  are  addressed  in  a  timely  manner, 
then  the  GBS  Phase  Two  system  will  support  the  use  of  UHF  DAMA  as  a  reach  back 


xin 


channel.    This  thesis  has  shown  that  UHF  DAM  A  can  be  a  viable  GBS  reach  back 
channel  if  certain  steps  are  taken  to  improve  efficiency. 
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I.  THE  GLOBAL  BROADCAST  SERVICE 

A.  HISTORY 

The  Global  Broadcast  Service  is  a  military  adaptation  of  the  civilian  direct 
broadcast  satellite  (DBS)  technology.  DBS  systems  use  high-power  geostationary 
satellites  to  deliver  over  one  hundred  channels  of  digital  audio  and  video  directly  to 
consumers.  The  high  power  satellite  transponders  (-53  dBW)  allow  the  use  of  relatively 
small  (18"  -  24")  consumer  antennas.  The  fact  that  industry  has  borne  the  majority  of  the 
research  and  development  costs  makes  this  technology  attractive  to  the  military.  The 
GBS  Concept  of  Operations  (CONOPS)  envisions  using  similar  commercial  technology 
to  support  the  warfighter.  The  types  of  information  and  products  delivered  over  GBS  will 
include  mission  data  updates  (MDUs),  air  tasking  orders  (ATOs),  Global  Command  and 
Control  System  (GCCS)  and  Joint  Maritime  Command  Information  System  (JMCIS) 
data,  meteorological  and  oceanographic  (METOC)  data  and  multiple  video  services.  A 
representative  list  of  data  products  identified  for  broadcast  over  GBS  by  United  States 
Pacific  Command  (PACOM)  is  provided  in  Appendix  A.  [Ref.  1] 

B.  THE  GBS  PROGRAM 
1.  Overview 

The  GBS  program  is  being  implemented  in  three  overlapping  phases.  Phase  one 
(FY96  -  FY98+)  consists  of  the  utilization  of  a  leased  Ku-Band  (14  gigahertz  (GHz) 
uplink,  12  GHz  downlink)  commercial  transponder  on  Hughes'  SBS-6  satellite  located  at 


74°  West  longitude.  Phase  two  (FY-98  -  FY09+)  of  the  GBS  program  consists  of  an 
interim  military  satellite  capability.  The  GBS  Phase  Two  Ka-Band  (30  GHz  uplink,  20 
GHz  downlink)  transponders  are  hosted  on  the  Ultra  High  Frequency  (UHF)  Follow-On 
(UFO)  satellites  8,  9,  and  10.  UFO  8  was  successfully  launched  on  March  16,  1998,  UFO 
9  is  scheduled  for  launch  in  August  1998,  and  UFO  10  is  scheduled  to  be  launched  in 
March  1999.  GBS  Phase  Two  will  not  provide  coverage  of  the  majority  of  the 
continental  United  States.  GBS  phase  three  (FY09+)  goals  include  worldwide  coverage 
and  the  complete  integration  of  GBS  into  the  Defense  Information  Infrastructure.  GBS 
will  support  the  Unclassified  through  Top  Secret  Sensitive  Compartmented  Information 
classification  levels.  [Ref.  1] 

The  GBS  program  incorporates  the  concepts  of  smart  push  and  user  pull.  The 
information  content  of  the  smart  push  is  determined  at  the  theater  level  without  real-time 
input  from  end-users  at  the  unit  level.  User  pull  allows  unit  level  end-users  to  define 
specific  information  to  be  broadcast  on  demand  in  response  to  operational  circumstances. 
User  pull  also  enables  end-users  to  request  that  certain  smart  push  products  be 
rebroadcast  in  the  event  that  they  were  not  received,  or  received  in  a  corrupted  form  at 
their  unit  during  the  regularly  scheduled  smart  push  broadcast.  Both  these  capabilities  are 
enabled  by  a  reach  back  channel.  The  reach  back  channel(s)  can  be  implemented  with 
any  suitable  means  of  communication  available  that  provides  connectivity  from  the  unit 
level  force  in  question  to  the  GBS  Satellite  Broadcast  Manager  (SBM).  [Ref.  1] 


The  actual  method  used  to  make  a  user  pull  request  will  depend  on  the  user's 
existing  communications  capabilities.  The  GBS  Phase  Two  CONOPS  specifies  four 
methods  of  user  pull  connectivity  shown  in  Table  1. 


Mode 

Retransmission 
Requests 

User  Pull  Requests 

Back  Channel 
(Example) 

Receive  Only 

N/A 

N/A 

N/A 

Manually  Connected 

Human-in-the-Loop 

Human-in-the-Loop 

Telephone 

Partially  Connected 

Human-in-the-Loop 

Human-in-the-Loop 

SIPRNET 

Fully  Connected 

Automatic  (Virtual 
Full  Duplex) 

Human-in-the-Loop 

SIPRNET 

Table  1  GBS  Reach  Back  Modes 
Regardless  of  the  connectivity  mode,  the  need  for  retransmission  requests  is 
detected  automatically  by  the  GBS  receiver  suite's  Receive  Broadcast  Manager  (RBM), 
and  user  pull  requests  are,  by  definition,  generated  manually.  In  Receive  Only  (RO) 
Mode,  the  unit  level  end-user  has  no  available  means  of  communication  except  a  GBS 
receiver.  It  is  therefore  not  possible  for  the  RO  user  to  submit  retransmission  or  user  pull 
requests.  The  Manually  Connected  (MC)  user  may  have  voice  or  dial-up  data 
communications  capabilities,  but  no  other  external  data  network  connectivity.  The  voice- 
only  MC  user  will  be  alerted  to  the  need  to  submit  a  retransmission  request  by  an 
indication  on  the  screen  of  the  RBM  or  an  end-user  terminal  connected  to  the  RBM.  The 
MC  user  with  dial-up  data  communications  will  make  use  of  an  RBM  utility  that  stores 
automatically  generated  retransmission  requests  in  properly  formatted  e-mail  text  files. 
Depending  on  the  internal  connectivity  at  the  unit  level,  the  MC  connected  GBS  user  will 
get  the  retransmission  request  message  file(s)  to  the  equipment  (typically  another 


computer)  that  has  the  dial-up  data  communications  connectivity  via  file  transfer  protocol 
(FTP),  internal  e-mail,  or  simply  copy  it  to  a  disc  and  "sneaker  net"  it.  Both  the  Partially 
Connected  (PC)  and  Fully  Connected  (FC)  modes  require  that  the  unit  level  end-user 
have  some  form  of  external  data  network  connectivity  and  that  the  GBS  RBM  is 
somehow  wired  to  this  connectivity  (e.g.,  via  a  ship's  onboard  Local  Area  Network  - 
LAN).  The  PC  user  does  not  have  full-time  external  data  network  connectivity  while  the 
FC  user  does.  The  PC  user's  external  network  connection  schedule  may  be  tied  to  reach 
back  satellite  access  periods.  The  PC  user  does  not  achieve  "virtual  full  duplex" 
connectivity  because  a  human-in-the-loop  (or  an  automated  process  external  to  the  RBM) 
is  required  to  ensure  that  GBS  retransmission  request  e-mail  queue  is  launched  when 
external  data  network  connectivity  is  available  (via  the  reach  back  channel).  Since  the  FC 
user  has  a  full-time  external  data  network  connection,  the  RBM-generated  retransmission 
requests  are  launched  automatically  without  a  human-in-the-loop  nor  the  need  for  any 
other  external  automated  process.  Therefore,  the  FC  GBS  user  achieves  "virtual  full 
duplex"  connectivity.  To  focus  on  the  performance  of  UHF  Demand  Assigned  Multiple 
Access  (DAMA)  Satellite  Communications  (SATCOM)  as  a  GBS  reach  back  channel, 
the  research  conducted  for  this  thesis  was  performed  with  the  NPS  GBS  receive  suite  in 
the  Fully  Connected  (FC)  mode.  [Ref.  1  Appendix  B] 

2.  Phase  One  GBS  System 

The  primary  purpose  of  the  Phase  One  system  is  the  refinement  of  the  CONOPS 
and  the  investigation  of  emergent  technologies  that  may  support  GBS  in  the  future.    In 


addition,  Phase  One  supports  the  Joint  Broadcast  Service  (JBS).  The  JBS  is  a  direct 
broadcast  capability  used  in  support  of  North  Atlantic  Treaty  Organization  operations  in 
Bosnia.  The  JBS  utilizes  the  Orion- 1  satellite  located  over  the  Atlantic  Ocean  at  37.5° 
West  longitude.  The  JBS  and  GBS  Phase  One  systems  share  a  satellite  uplink  facility  the 
JBS  Information  Management  Center  (JIMC)  which  is  currently  located  in  the  Pentagon. 
[Ref.  1] 

The  Phase  One  GBS  broadcast  is  approximately  23  megabits  per  second  (Mbps) 
and  is  subdivided  into  channels.  The  broadcast  uses  the  proprietary  Hughes  Corporation 
Direct  Satellite  System  (DSS)  waveform  for  data  transmission  [Ref.  5].  Typical  channels 
include  secret  Internet  protocol  (IP)  data,  unclassified  IP  data,  secret  asynchronous 
transfer  mode  (ATM)  data,  and  a  video  broadcast. 

Figure  1  shows  the  components  of  a  Phase  One  receive  suite  involved  in  the 
reception  of  an  IP  data  channel.  The  broadcast  is  received  by  a  1  meter  satellite  dish, 
downconverted  to  an  L-Band  intermediate  frequency,  and  sent  to  the  integrated  receiver 
decoder  (IRD).  The  IRD  is  the  "set  top  box"  that  allows  one  to  select  the  desired 
channel.  The  data  output  of  the  IRD  is  a  15  pin  parallel  data  port.  The  data  bridge 
converts  the  parallel  output  of  the  IRD  into  a  serial  data  stream  for  decryption  by  the  KG- 
194A.  The  IP  channel  is  typically  operated  at  a  data  rate  of  4  Mbps.  The  KG- 194 A 
decrypts  the  signal  and  provides  an  input  to  the  one  of  the  serial  ports  on  the  Cisco  router. 
The  Cisco  router  converts  the  serial  data  into  the  Ethernet  protocol  which  allows  a  simple 
interface  with  the  Sun  workstation.    For  a  more  detailed  discussion  including  directions 


on  how  to  develop  a  GBS  Phase  One  receive  suite  from  commercial  components  see 
Schaffler  [Ref.  4].  The  Phase  One  GBS  broadcast  uses  the  User  Datagram  Protocol 
(UDP)  at  the  transport  layer.  UDP  is  a  connectionless  IP  based  protocol.  Connectionless 
means  that  each  data  packet  is  not  acknowledged.  Multiple  transmissions  are  used  to 
make  a  best-effort  at  delivery,  but  there  is  no  way  to  ensure  the  data  has  been  received 
correctly  on  a  packet-by-packet  basis. 
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Figure  1  GBS  Phase  One  Receive  Suite 

-  a)         GBS  Reach  Back  via  Phase  One  Systems 

Since  GBS  is  a  simplex  link  there  are  numerous  methods  used  to  ensure 
reception.  For  example,  transmissions  are  typically  repeated  3  times  and  may  be  repeated 
up  to  30  times  to  help  ensure  reception.  Forward  error  correction  allows  the  link  to 
operate  at  a  bit  error  rate  of  less  that  1x10-10,  reducing  corrupted  files  and  therefore 


reducing  the  need  to  retransmit.  The  only  reach  back  communication  methods  available 
in  the  GBS  Phase  One  software  are  the  automatic  and  manual  retransmit  requests.  The 
uplink  site  periodically  transmits  a  list  of  all  files  that  have  been  broadcast.  The  receive 
data  manager  (RDM)  compares  that  list  of  files  with  the  files  that  have  been  received. 
(The  GBS  Phase  One  RDM  is  referred  to  as  the  receive  broadcast  manager  (RBM)  in  the 
Phase  Two  systems.)  If  there  are  files  which  have  not  been  received  there  are  two 
methods  to  request  retransmission.  In  the  automatic  retransmit  mode  the  RDM 
establishes  a  Transmission  Control  Protocol  /  Internet  Protocol  (TCP/IP)  session  between 
the  GBS  gateway  computer  and  the  RDM.  The  RDM  then  requests  the  files  that  are 
missing.  In  the  manual  retransmit  mode  the  RDM  operator  selects  a  file  or  multiple  files 
in  the  RDM  X- Windows  file  manager  and  clicks  on  the  retransmit  icon.  This  method 
uses  the  same  procedure  as  the  automatic  retransmit  request  with  only  the  selected  files 
being  requested  for  retransmission.  The  full  TCP/IP  retransmit  request  for  a  single  file 
typically  consists  of  approximately  200  bytes  in  the  forward  direction  (from  the  RDM  to 
the  GBS  gateway  computer)  and  100  bytes  in  the  return  path.  The  retransmit  request 
executes  a  common  gateway  interface  (CGI)  script  at  the  GBS  gateway.  The  CGI  script 
queues  up  the  file(s)  for  retransmission.  These  files  are  then  rebroadcast  via  the  GBS  link 
provided  they  are  still  available  at  the  gateway  computer.  If  they  are  not  available  the 
operator  is  notified  by  the  gateway  computer  that  the  retransmit  request  has  failed  before 
the  TCP  connection  is  closed.  [Ref.  2] 


In  the  experiment  discussed  in  Chapter  III  the  manual  retransmit  request 
will  be  utilized.  This  is  the  most  likely  configuration  for  a  GBS  user  for  whom  UHF 
DAMA  is  the  primary  means  of  long  haul  communications.  The  fact  that  the  retransmit 
request  consists  of  a  TCP/IP  session  allows  us  to  extrapolate  the  results  to  other 
scenarios.  For  example,  the  request  could  be  the  acknowledgment  of  a  high  priority 
message.  In  addition,  the  PACOM  CONOPS  [Ref.  3]  describes  a  scenario  that  has 
similarities  to  the  manual  reach  back  request.  According  to  the  PACOM  CONOPS  the 
GBS  satellite  broadcast  manager  will  develop  and  broadcast  a  catalog  of  information 
products.  Users  may  then  subscribe  or  request  these  information  products  via  alternate 
communications  systems,  for  example,  UHF  DAMA. 

3.  Phase  Two  GBS  System 

The  GBS  Phase  Two  system  is  composed  of  three  major  segments,  the  satellite 

broadcast  manager  (SBM),  receive  broadcast  manager  (RBM),  and  the  space  segment.  I 
will  concentrate  on  the  RBM  and  the  space  segment.  Currently  it  is  planned  that  the 
RBM  will  use  the  Microsoft  NT  Version  4.0  operating  system  and  Internet  Explorer  4.0 
as  the  web  browser  to  access  the  information.  There  are  numerous  configuration  options 
for  the  Phase  Two  receive  suite.  The  main  differences  between  the  receive  suite 
configurations  are  the  number  and  types  of  video  and  data  feeds.  The  broadcast  uses  the 
European  Digital  Video  Broadcast  Standard  (DVB).  DVB  was  chosen  for  a  number  of 
reasons  including  its  ability  to  support  variable  data  rates.  For  a  more  detailed 
comparison  of  DVB  and  the  Hughes'  DSS  standard  see  Wellborn  [Ref.  5]. 


When  fully  implemented  the  GBS  Phase  Two  system  will  provide  coverage  as 
shown  in  Figure  2.  The  majority  of  the  receive  suites  for  the  Phase  Two  system  will 
include  dual  band  capability.  Dual  band  receivers  allow  the  augmentation  of  the  military 
Ka-band  systems  with  commercial  Ku-band  capability.  This  will  be  especially  important 
since  there  will  not  be  any  GBS  coverage  in  the  central  portion  of  the  Continental  United 
States. 


Legend 

5Maaf 
Spasm™ 

'  "  '"'■, 

2000nmi 
Wide  Area  Beam 

1 

-180.      -150.      -120.       -90.0      -60.0      -30.0        0.0         30.0        60.0        90.0        120.        150.     180 

Satellite  Locations: 

UFO-8:      172E 

UFO-9:      2Z5VV  broadcast    The  spot  beams  can  be  moved  throughout  the  satellite 

UFO-10:    72E  coverage  area  as  directed  by  operational  CINCs 


LOnaitllde  Each  UF0  Sa,ellite  has  tw0  50°  NM  SP°'  beams  (l, 2)  and  one  2000  NM 

beam  (3)    Receive  Suites  must  be  inside  one  of  these  beams  to  receive  the 


Figure  2  GBS  Phase  Two  Coverage 
[Ref.  3] 


The  Phase  Two  space  segment  consists  of  four  transponders,  two  uplink  antennas, 
one  of  which  is  steerable,  and  three  steerable  downlink  antennas  on  each  satellite.  (Refer 
to  Figure  3.)   Each  transponder  is  rated  for  130  watts  of  transmit  power  and  has  a  3  dB 


uplink  bandwidth  of  33  Megahertz.    The  transponder  center  frequencies  are  shown  in 
Table  2.  [Ref.  6] 

The  fixed  uplink  antenna  for  each  satellite  will  be  pointed  at  a  primary  injection 
point  (PIP).  The  PIPs  will  be  located  in  Wahiawa,  HI;  Norfolk,  VA;  and  Sigonella,  Italy. 
The  steerable  uplink  antenna  may  be  pointed  to  receive  information  from  up  to  three 
theater  injection  points  (TIP).  If  multiple  TIPs  are  used  each  would  be  assigned  to  a 
separate  transponder  and  they  must  all  be  within  a  single  350  NM  diameter  as  determined 
by  the  footprint  of  the  steerable  uplink  antenna.  [Ref.  1  ] 


Transponder  Channel 

Uplink  Center  Frequency 
(GHz) 

Downlink  Center  Frequency 
(GHz) 

1 

30.095 

20.295 

2 

30.215 

20.415 

3 

30.275 

20.475 

4 

30.395 

20.595 

Table  2  GBS  Transponder  Center  Frequencies 
[Ref.  6] 

The  GBS  Phase  Two  space  segment  is  shown  in  Figure  3.  The  downlink  antennas 
offer  two  distinctive  broadcast  patterns,  one  2000  nautical  mile  (NM)  wide  area  coverage 
beam  (at  nadir)  and  two  500  NM  spot  beams  (at  nadir).  The  wide  area  coverage  beam 
provides  a  1.544  Mbps  data  rate  while  the  spot  beams  offer  a  24  Mbps  data  rate.  The 
downlink  antennas  may  be  configured  to  provide  up  to  four  simultaneous  24  Mbps  data 
streams  distributed  between  the  two  spot  beams,  or  three  24  Mbps  data  streams 
distributed  between  the  two  spot  beams  and  one  1 .544  Mbps  wide  area  beam.  [Ref.  1] 


10 


Fixed  &  Steerable  Uplinks        Transponders  Downlink 

Broadcast  Injection  p  Steerable  Spot  Beams 


Primary 
Injection 
Terminal 


•footdi 
Theater  Injection 
Terminal(s) 


2.7  dB/°K  (Rain):  +15.2QBPK  (Clear) 


Figure  3  GBS  Phase  Two  Space  Segment 
[Ref.  3] 

a)         GBS  Reach  back  via  Phase  Two  Systems 

The  GBS  Phase  Two  broadcast  will  also  consist  of  smart  push  and  user 
pull  components.  The  SBM  will  maintain  smart  push  interest  profiles  for  individual 
units,  battle  groups,  etc.  These  will  be  set  up  as  "channels"  to  information  source  web 
sites  defined  by  ".cdf '  files  using  the  Microsoft  FrontPage  software  product.  (Note: 
Information  providers  who  desire  their  products  to  be  distributed  via  GBS  will  have  to 
make  them  available  at  web  sites  on  the  SIPRNET  or  the  NIPRNET.)  The  .cdf  files  then 
direct  the  operation  of  an  automated  search  engine,  i.e.,  a  "web  crawler."  The  web 
crawler  copies  updates  of  desired  information  from  the  sites  contained  in  the  .cdf  files  to 
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a  cache  at  the  SBM.  These  are  then  smartly  pushed  to  the  unit  level  receive  terminals 
according  to  the  broadcast  access  schedule  (i.e.,  the  pointing  schedules  of  the  downlink 
beams)  where  they  reside  on  the  unit  level  users'  RBMs.  The  RBMs  become,  in  effect, 
proxy  web  servers  for  the  individual  end-users  whose  workstations  will  be  connected  to 
the  RBM  via  a  LAN  or  other  means.  The  content  of  the  smart  push  portion  of  each 
broadcast  is  catalogued  in  the  electronic  program  guide  (EPG)  which  is  also  transmitted 
with  the  broadcast. 

In  addition  to  the  smart  push  products,  the  Phase  Two  GBS  SBM  will 
maintain  a  menu  (in  hypertext  format)  of  products  available  for  user  pull.  The  SBM  will 
download  the  current  version  of  the  user  pull  menu  to  the  unit  level  users  with  each 
broadcast  along  with  the  EPG.  Users  will  click  on  hypertext  links  to  make  requests  from 
the  available  list  of  user  pull  information  products.  In  response,  the  RBM  generates  an 
email  message  addressed  to  the  SBM  which  will  be  sent  via  the  reach  back  channel.  The 
email  message  will  be  acknowledged  as  soon  as  possible  by  the  SBM  via  the  reach  back 
channel,  but  the  scheduling  of  the  actual  user  pull  data  delivery  via  the  broadcast  will 
depend  on  CINC  priorities  and  bandwidth  availability.  [Ref.  9] 

The  Microsoft  Point-to-Point  Tunneling  Protocol  (PPTP)  is  responsible  for 
routing  reach  back  email  messages  from  the  RBM  to  the  SBM.  PPTP  is  a  built-in  option 
in  Microsoft  NT  Version  4.0,  and  is  planned  for  NT  Version  5.0.  In  addition,  Windows 
95  users  can  download  an  add-on  which  will  allow  them  to  establish  a  PPTP  tunnel 
between  a  Windows  95  client  computer  and  an  NT  Server.  A  sample  PPTP  connection  is 
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shown  in  Figure  4.  The  purpose  of  PPTP  is  to  securely  connect  a  private  network  to  a 
remote  access  client.  PPTP  relieves  the  planners  of  some  of  the  Internet  Protocol  (IP) 
addressing  requirements.  As  can  be  seen  in  Figure  4,  the  actual  addresses  of  the 
computers  are  not  used  through  the  Internet,  only  the  PPTP  tunnel  addresses.  [Refs.  9, 
21] 
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Figure  4  PPTP  Connection 
[Ref.21] 

C.         GBS  REACH  BACK  EXPERIMENTS 

Since  the  first  days  of  the  GBS  experiments  there  has  been  interest  in  how  to 
deliver  requests  for  information  from  users.  The  Joint  Staff  sponsors  an  exercise  every 
year  called  the  Joint  Warrior  Interoperability  Demonstration  (JWID).  The  purpose  of  the 
JWID  exercise  is  to  examine  emerging  technology  and  investigate  how  that  technology 
may  support  the  warfighter.  The  subject  of  GBS  reach  back  has  been  a  topic  in  at  least 
two  previous  JWID  exercises  and  is  planned  for  a  third. 
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1.  JWID 1996 

The  Army  sponsored  a  demonstration  using  the  Extremely  High  Frequency  (EHF) 

MILSTAR  SATCOM  system  as  a  reach  back  channel  for  GBS.  The  MILSTAR  System 
provided  a  dedicated  2400  bps  point-to-point  link  between  remote  users  and  the  Joint 
Task  Force  Headquarters.  The  demonstration  was  hosted  onboard  the  USS  Kearsarge, 
and  at  Fort  Bragg,  NC.  The  operators  used  INTELINK-X  menu  based  software  written 
by  the  Air  Intelligence  Agency  and  an  All  Source  Analysis  System  -  Remote  Workstation 
to  communicate  directly  with  information  providers  via  the  Secure  Internet  Protocol 
Routed  Network  (SIPRNET).  The  requested  information  was  wrapped  and  delivered  via 
the  SIPRNET  to  the  GBS  uplink  facility.  The  request-to-receipt  cycle  time  was  typically 
three  to  five  minutes,  with  some  exceptions  taking  up  to  15  minutes.  The  exceptionally 
long  delivery  times  were  attributable  to  the  GBS  broadcast  queue  length  and  poor 
weather  conditions  at  the  uplink  facility  which  disrupted  the  uplink  signal.  [Ref.  10] 

2.  JWID  1997 

The  National  Reconnaissance  Office  (NRO)  Operational  Support  Office  (OSO) 
sponsored  a  GBS  reach  back  demonstration  during  JWID  1997.  The  reach  back  channel 
actually  utilized  available  unused  bandwidth  on  the  SBS-6  transponder  used  for  the  GBS 
Phase  One  broadcast.  Specifically  they  used  a  100  watt  transmitter,  spread  spectrum 
modulation,  and  a  1 .2  meter  antenna.  The  reach  back  channel  operated  at  40  kilobits  per 
second  (kbps).  Spread  spectrum  modulation  was  used  to  reduce  the  signal  power  density 
and  avoid  adjacent  satellite  interference  which  is  problematic  when  using  a  small  uplink 
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antenna.  The  demonstration  typically  received  the  requested  data  within  five  minutes, 
with  some  exceptions  taking  up  to  30  -  40  minutes.  The  longer  transfer  times  were  again 
attributable  to  queuing  delays  at  the  uplink  facility.  There  did  not  seem  to  be  any 
correlation  between  file  size  and  delivery  time.  The  demonstration  was  hosted  at  Fort 
Gordon,  GA  and  was  a  proof  of  concept  and  did  not  allow  for  other  units  to  utilize  the 
reach  back  channel.  The  technique  will  actually  not  work  in  GBS  Phase  Two  because  all 
in-theater  uplinking  capability  in  Phase  Two  is  intended  for  the  TIPs,  not  end  users.  If 
end  users  were  to  use  the  Phase  Two  uplink  for  reach  back,  they  would  need  powerful 
transmitters  at  30  GHz  (see  Table  2).  Also,  the  footprint  of  the  Phase  Two  steerable 
uplink  spot  beam  would  have  to  be  pointed  to  include  their  location.  [Ref.  11] 

3.  Naval  Research  Laboratory  Experiments 

In  December  1997  the  Naval  Research  Laboratory  (NRL)  began  a  set  of 
experiments  that  took  the  concept  of  GBS  reach  back  one  step  further.  The  NRL  has 
demonstrated  the  capability  to  access  a  world  wide  web  server  via  multiple  reach  back 
channels  such  as  a  dial  up  telephone  line,  cellular  phone,  dedicated  25-kHz  UHF 
SATCOM,  and  the  Planet  One  Data  Phone.  The  Phase  One  GBS  was  used  to  deliver  the 
web  pages.  The  Planet  One  Data  Phone  is  2.4  kbps  data  service  provided  by  the 
International  Maritime  Satellite  Organization  (INMARSAT).  The  goal  of  the  experiment 
was  to  demonstrate  smart  "user  pull"  of  data  over  the  GBS  system  using  standard 
protocols.  [Ref.  13] 
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4.  JWID 1998 

The  NRO/OSO  and  NRL  have  submitted  a  proposal  that  builds  upon  the  NRL 
experiment.  The  proposed  JWID  1998  demonstration  includes  web  browsing  via  all  of 
the  reach  back  channels  in  the  NRL  demonstration  in  addition  to  a  very  small  aperture 
terminal  (VSAT)  code  division  multiple  access  (CDMA)  SATCOM  system.  There  will 
also  be  additional  users:  the  proposal  includes  two  shore-based  users  and  one  afloat  user. 
[Ref.  12] 
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II.         ULTRA  HIGH  FREQUENCY  DEMAND  ASSIGNED  MULTIPLE  ACCESS 

SATELLITE  COMMUNICATIONS 


A.         DAMA  BACKGROUND 

The  ever-increasing  demand  for  UHF  satellite  communications  has  led  to  the 
saturation  of  the  existing  UHF  SATCOM  assets.  In  the  1970s  Demand  Assigned 
Multiple  Access  (DAMA)  was  developed  as  a  method  for  multiple  users  to  share  a  single 
communications  channel.  DAMA  is  basically  a  form  of  time  division  multiple  access 
(TDMA)  where  the  channel  is  partitioned  into  time  slots  which  can  then  be  assigned  on  a 
dynamic  basis.  There  are  several  methods  to  access  a  time  slot  on  a  DAMA  channel. 

In  1986  the  Navy  implemented  DAMA  in  the  distributed  control  (DC)  mode.  The 
DC  mode  involved  centralized  assignment  of  time  slots  within  the  SATCOM  channel. 
The  control  site  determined  how  the  DAMA  slots  would  be  allocated  and  distributed  a 
message  with  the  assignments.  For  example,  if  there  was  a  net  operating  on  time  slot 
10158  that  a  ship  needed  to  participate  in,  then  the  radiomen  aboard  ship  would  enter  this 
time  slot  number  into  the  DAMA  terminal.  This  would  allow  that  ship  to  participate  in 
that  DAMA  net.  In  the  DC  mode  there  was  no  dynamic  reallocation  of  bandwidth.  [Ref. 
7] 

In  the  automatic  control  (AC)  mode  a  time  slot  is  requested  from  a  central 
controller  via  a  satellite  orderwire,  assigned  to  a  terminal,  and  released  back  to  the 
controller  once  the  terminal  has  completed  using  it.  In  the  AC  mode  DAMA  terminals 
are  identified  by  a  unique  address.  The  ability  to  identify  the  terminals  allows  a  DAMA 
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controller  to  verify  that  the  requesting  terminal  is  authorized  to  initiate  or  join  a  net,  in 
addition  to  determining  its  priority.  An  additional  capability  when  operating  in  the  AC 
mode  of  operation  is  called  demand  assigned  single  access  (DASA).  The  DASA  mode 
allows  a  single  user  access  to  an  entire  channel  without  having  to  share  the  bandwidth. 
The  request  for  a  DASA  channel  is  made  via  the  user's  UHF  DAMA  channel.  In  the 
DASA  mode  of  operation  once  the  channel  has  been  assigned  to  a  user  it  is  operated  in 
the  dedicated  UHF  SATCOM  mode  (MIL-STD-1 88-181).  The  DASA  channel  is 
allocated  for  a  fixed  time  period.  The  user  retains  use  of  the  DASA  channel  until  he 
voluntarily  gives  the  channel  up  and  logs  back  onto  his  home  channel  or  the  timer 
expires.  DASA  channels  cannot  be  preempted.  [Ref.  7] 

There  are  currently  two  different  UHF  DAMA  SATCOM  waveforms,  one  for 
operation  over  5-kilohertz  (kHz)  channels,  and  one  for  operation  over  25-kHz  channels. 
The  Navy  has  focused  on  the  development  of  the  25-kHz  DAMA  controllers  and 
terminals  (MIL-STD-1 88-1 83)  for  both  ships  and  aircraft,  while  the  Air  Force  has 
concentrated  on  the  5-kHz  DAMA  controllers  and  terminals  (MIL-STD-1 88-1 82). 

B.         25-KHZ  DAMA 

The    25-kHz    DAMA    waveform    has    a    relatively    short    frame    length    of 

approximately  1.3866  seconds  (Figure  5).  The  user  segments  are  capable  of  being 
subdivided  into  over  1500  different  frame  format  combinations,  allowing  users  to  select 
setups  that  would  best  fit  their  needs.  A  CINC  communications  planner  typically 
specifies  the  frame  formats.   For  example,  the  Navy  often  uses  Frame  Format  259  which 


18 


provides  five  2400  bit  per  second  (bps)  voice  or  data  slots  in  addition  to  twelve  75  bps 
slots  and  one  300  bps  slot. 

When  operated  in  the  AC  mode,  the  25-kHz  waveform  supports  point-to-point, 
conference,  and  network  calls.  The  baseband  data  rates  supported  range  from  75  bps  -  16 
kilobits  per  second  (kbps).  If  the  1 6  kbps  data  rate  is  selected  it  occupies  all  of  segments 
B  and  C,  leaving  only  segment  A  for  other  users.  The  minimum  time  to  request  and 
access  a  time  slot  is  three  frames,  one  frame  to  request  the  slot,  one  for  the  controller  to 
process  the  request,  and  the  third  for  the  controller's  reply.  The  terminal  is  allowed  to 
start  transmitting  during  the  same  frame  that  the  reply  is  received.  A  typical  time  would 
then  be  3  frames  plus  two  satellite  hop  delays,  approximately  4.6  seconds  total.  [Ref.  7] 
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Figure  5  25-kHz  DAMA  Frame 
[Ref.  7] 
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C.         5-KHZ  DAMA 

The  5-kHz  DAMA  frame  is  shown  in  Figure  6.  5-kHz  DAMA  was  designed  for 
short  data  messages,  low  speed  data  circuits,  and  limited  secure  voice  capability  for  the 
Air  Force's  Military  Airlift  Command  (now  Air  Mobility  Command).  The  capabilities  of 
5-kHz  DAMA  include  packetized  message  service,  voice,  and  data  circuit  service.  The 
entire  5-kHz  frame  is  8.96  seconds  in  duration,  but  the  lengths  of  the  time  slots  assigned 
for  circuit  use  within  the  frame  vary  with  the  type  of  data,  modulation,  and  code  rate. 
The  length  of  the  time  slots  used  for  messaging  can  vary  depending  on  the  amount  of 
unused  space  in  each  frame.  The  packetized  message  service  allows  up  to  900  messages 
per  hour  with  an  average  message  size  of  200  characters.  The  messages  are  typically 
generated  on  a  laptop  computer  and  stored  until  the  terminal  is  granted  access  to  the 
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[Ref.  7] 
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channel.  The  frame  length  of  almost  9  seconds  may  cause  problems  with  voice  and  data 
circuits.  The  minimum  time  to  set  up  a  channel  is  also  3  frame  cycles  or  almost  27 
seconds  and  could  be  longer  if  more,  higher  priority  users  are  competing  for  the  channel. 
Once  the  circuit  is  established  the  worst  case  delay  would  be  at  most  two  frames  which 
makes  full  duplex  data  communications  difficult,  and  voice  communications  even  more 
difficult.  Because  of  these  delays,  25-kHz  DAMA  with  its  quicker  cycle  time  or  5-kHz 
DAS  A  are  preferred  for  voice  communications.  A  5 -kHz  DAS  A  circuit  may  be  set  up 
using  a  25-kHz  channel  or  a  5-kHz  channel  to  request  the  circuit.  The  use  of  a  25-kHz 
channel  greatly  decreases  the  setup  time.  In  the  DASA  mode  of  operation  once  the 
channel  has  been  assigned  there  are  no  framing  delays,  only  the  satellite  delay.  [Ref.  7] 

D.         TCP/IP  OVER  UHF  DAMA 

DAMA    is    not    an    efficient    transmission    protocol    for    many    computer 

communications.  Protocols  like  TCP/IP  have  been  optimized  to  operate  over  terrestrial 
links  such  as  phone  lines,  fiber  optic  systems,  etc.  As  mentioned  earlier  the  frame  delay 
for  a  25-kHz  signal  is  approximately  1 .4  seconds,  and  for  a  5-kHz  signal  is  on  the  order 
of  9  seconds  after  the  connection  has  been  established.  Depending  on  their  location  in  the 
frames,  two  users  who  are  communicating  may  experience  up  to  two  frames  of  delay. 
Geosynchronous  satellites  add  to  this  problem  with  a  round  trip  delay  of  approximately 
0.5  seconds  to  transmit  a  signal  and  receive  a  reply.  These  delays  can  wreak  havoc  on 
computer  protocols. 
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For  example,  if  a  system  wanted  to  establish  a  TCP  session  with  another  computer 
it  must  complete  what  is  known  as  a  three-way  handshake.  The  originating  computer 
sends  a  TCP  packet  with  the  synchronize  (S YN)  flag  set.  If  the  destination  computer  is 
available,  it  will  reply  with  an  acknowledgment  packet.  The  originating  computer  will 
then  acknowledge  this  packet,  thereby  completing  the  three-way  handshake.  Once  the 
three-way  handshake  is  completed  the  data  communications  may  begin.  If  the  SYN  is 
not  acknowledged  within  a  certain  period  of  time  the  originating  computer  resets  the 
connection.  The  actual  amount  of  time  each  a  computer  will  wait  to  establish  a 
connection  varies  with  the  operating  system.  Once  the  three-way  handshake  has  been 
completed  data  can  begin  to  be  transferred.  [Ref.  8] 

There  are  two  timing  problems  that  computers  face  with  using  DAMA.  The  first 
is  the  setup  of  the  DAMA  connection.  As  mentioned  earlier  it  takes  up  to  three  frames  to 
setup  the  connection.  The  second  is  the  framing  delays  in  between  communications  once 
the  connection  has  been  established,  the  worst  case  scenario  is  approximately  two  frames. 
After  completing  the  three-way  handshake  the  computer  may  begin  communications. 
Each  computer  maintains  a  retransmission  timer  that  is  typically  set  at  three  seconds.  If 
the  destination  computer  does  not  respond  within  three  seconds  then  the  last  packet  is 
resent.  If  there  was  no  reply  to  the  second  packet  the  TCP  protocol  begins  an  exponential 
back  off  where  the  time  it  waits  to  resend  the  packet  doubles.  It  should  be  obvious  that 
even  with  the  relatively  short  25-kHz  frames  there  may  be  two  frame  delays  and  two 
satellite  delays  in  between  communications.    These  delays  would  be  approximately  3.3 
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seconds,  long  enough  to  trigger  the  retransmission  timer.    In  order  to  efficiently  utilize 
DAMA  for  TCP/IP  an  additional  layer  of  complexity  must  be  added. 

E.         IMPLEMENTATIONS  OF  TCP/IP  OVER  DAMA 

There  are  many  different  ways  to  approach  the  problem  of  using  UHF  DAMA  as 
a  transmission  channel  for  TCP/IP.  One  such  solution  is  the  Automatic  Data 
Controller/Internet  Protocol  (ADC/IP)  Data  Controller  developed  by  ViaSat.  The 
ADC/IP  has  integrated  a  proxy  server  within  the  controller  which  acknowledges  the 
packets  as  they  are  sent  from  the  originating  computer,  buffers  them,  and  sends  them  out. 
The  ADC/IP  uses  carrier  sense  multiple  access  (CSMA)  without  collision  detect  to  access 
a  DAS  A  channel.  The  advantage  of  the  ADC/IP  approach  is  that  for  the  sending 
computer  the  use  of  DAMA  as  the  transmission  channel  is  transparent.  The  disadvantage 
is  if  the  connection  is  lost  there  is  no  way  to  gracefully  degrade  the  connection.  This  is 
because  the  packets  have  already  been  acknowledged  and  the  whole  TCP  session  is  just 
dropped  and  must  be  restarted.  When  compared  with  the  ADNS  channel  access  methods 
the  use  of  CSMA  minimizes  the  channel  access  delay  at  the  cost  of  reduced  efficiency  at 
higher  traffic  loads.  In  addition,  the  use  of  a  DASA  channel  somewhat  defeats  the 
purpose  of  DAMA  (because  it  can  not  be  preempted)  although  the  channel  would  be 
available  for  reassignment  if  it  was  released.  [Ref.  14] 

The  Joint  Maritime  Communications  Strategy  (JMCOMS)  is  a  Navy  program 
developed  to  implement  the  Navy's  Copernicus  vision.  A  major  portion  of  JMCOMS  is 
the  Automated  Digital  Network  System  (ADNS).    The  goal  of  ADNS  is  to  provide 
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seamless,  secure  multimedia  connectivity.  A  significant  portion  of  the  ADNS  program  is 
the  automated  network  routing  and  switching  function,  which  will  allow  the  multiplexing 
of  all  traffic  types  over  available  Radio  Frequency  (RF)  assets.  For  example,  on  an 
aircraft  carrier  (refer  to  Figure  7)  ADNS  would  multiplex  signals  through  systems  such  as 
Super  High  Frequency  (SHF)  SATCOM,  EHF  SATCOM,  and  UHF  DAMA  SATCOM. 
[Ref.  15] 

To  enable  the  systems  to  function  seamlessly  over  such  diverse  RF  links,  ADNS 
has  developed  channel  access  protocols  (CAPs).  One  of  these  is  the  UHF  DAMA  CAP. 
A  goal  of  this  thesis  is  to  examine  the  performance  of  GBS  reach  back  over  UFLF  DAMA 
when  this  ADNS  CAP  is  employed.  The  typical  mode  of  operation  for  ADNS  and  UHF 
DAMA  for  the  Navy  is  the  assignment  of  a  2.4  kbps  slot  on  a  25-kHz  DAMA  channel. 
The  TD-1271  B/U  is  the  DAMA  satellite  modem/multiplexer  used  by  ADNS  and  is 
capable  of  supporting  four  baseband  channels. 

The  ADNS  UHF  DAMA  CAP  functions  slightly  differently  from  the  ADC/IP 
described  above.  The  key  to  TCP/IP  over  DAMA  for  ADNS  is  the  CAP  Router  Interface 
Unit  (CRIU),  see  Figure  7.  Consider  the  example  mentioned  earlier  -  the  three-way 
handshake  to  establish  a  TCP  session.  Since  the  channel  has  a  relatively  high  latency  it  is 
probable  that  the  sending  computer  will  have  generated  duplicate  packets  due  to  the 
retransmission  timer.  The  ADNS  CRIU  deletes  these  duplicate  packets  generated  by  the 
originating  computer  rather  than  send  them  over  an  already  bandwidth  limited  link.  If  the 
buffer  begins  to  fill  up,  the  CRIU  will  send  an  Internet  Control  Message  Protocol  source 
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quench  message  to  the  originating  computer.  The  purpose  of  the  source  quench  message 
is  to  stop  the  extra  packets  from  cluttering  up  the  local  area  network  until  the  destination 
computer  has  had  a  chance  to  respond.  The  CRIU  is  responsible  for  monitoring  the  link 
and  in  effect  developing  its  own  retransmission  timer  based  on  channel  latency  to 
determine  when  a  packet  may  have  been  lost.  The  channel  access  method  used  by  ADNS 
is  variable  slot  TDMA  with  reservation.  It  has  guaranteed  minimum  access,  allowing 
users  to  reserve  a  time  slot  and  expand  their  access  by  request.  The  typical  maximum 
number  of  simultaneous  TCP/IP  users  that  the  ADNS  UHF  DAMA  CAP  is  four.    [Ref. 
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Figure  8  shows  a  notional  ADNS  UHF  CAP  configuration  with  two  users,  each 
with  one  frame  of  data.  The  DAMA  channel  that  is  assigned  to  ADNS  is  2.4  kbps; 
therefore  the  number  of  bits  available  each  frame  is  2400bits  I  sec*  1.3866  sec  =  33327 bits 
or  approximately  416  bytes.  Within  the  UHF  DAMA  CAP  each  user  can  be  assigned  up 
to  8  time  slots,  there  can  be  up  to  four  users,  and  since  each  user  is  half-duplex  there  must 
be  one  blank  frame  in  between  users  so  other  users  can  be  sure  that  the  previous  user  is 
finished.  In  addition,  there  is  a  network  join  frame  which  allows  a  node  to  request  entry 
into  an  existing  network  and  the  associated  blank  DAMA  frame  at  the  end  of  the  ADNS 
frame.  The  total  cycle  time  with  four  users,  each  with  the  maximum  amount  of  data  is 
((4users *  9 frames)  +  (ladd  +  Xblank))  *  1.3866sec/  frame  =  52.69 sec  .  This  was  designed 
to  limit  the  total  cycle  time  to  under  one  minute  to  support  TCP  applications  such  as  the 
file  transfer  protocol  (FTP).  When  compared  with  the  ADC/IP,  the  ADNS  channel 
access  method  is  less  efficient  at  lower  loads  (e.g.  one  user  with  one  data  frame  would 
result  in  at  least  a  75%  overhead),  but  more  efficient  as  the  net  becomes  congested. 
[Refs.  15,  16] 
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F.         TCP/IP  OVER  DAMA  SUMMARY 

There  are  quite  a  few  problems  inherent  with  attempting  a  TCP/IP  data  connection 
using  UHF  DAMA.  TCP/IP  has  not  been  optimized  to  operate  over  high  latency  links. 
The  UHF  DAMA  5-kHz  and  25-kHz  frame  structures  incur  relatively  high  latencies. 
Because  of  DAMA' s  framing  delays,  it  cannot  support  a  direct  connection  between  two 
computers  without  a  third  party  system  which  governs  data  access  to  the  channel  or  time 
slot.  It  is  the  performance  of  just  such  a  third  party  system,  the  ADNS  UHF  DAMA 
CAP,  that  will  be  investigated  in  the  following  chapters. 
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III.       EXPERIMENT  SETUP 

A.         BACKGROUND 

The  Naval  Postgraduate  School  (NPS)  established  a  GBS  receive  suite  in  the 
Spring  of  1997.  [Refs.  4,  18]  The  lab  is  used  primarily  for  thesis  research  and  GBS 
experimentation.  [Refs.  5,  17]  The  lab  configuration  is  shown  in  Figure  9.  The  GBS 
Receive  Data  Manager  (RDM)  was  initially  installed  in  a  receive-only  configuration. 
Therefore  the  initial  step  in  preparation  for  this  experiment  was  to  configure  the  RDM  to 
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allow  reach  back  communications  with  the  GBS  gateway  at  the  JIMC  in  the  Pentagon. 
The  NPS  GBS  Test  Bed  already  had  Secure  Internet  Protocol  Routed  Network 
(SIPRNET)  connectivity  when  this  work  started.  A  SIPRNET  connection  was  added  to 
the  RDM  (as  shown  in  Figure  9)  and  it  was  confirmed  that  files  could  be  requested  from 
the  GBS  gateway  directly  through  the  SIPRNET  with  the  GBS  Phase  One  software. 
Once  this  was  completed,  the  various  segments  of  the  UHF  DAMA  SIPRNET  connection 
were  added  in  one  at  a  time.  Troubleshooting  was  performed  on  each  segment  as  it  was 
added. 

B.         TEST  CONFIGURATION 

The  GBS  reach  back  test  configuration  is  show  in  Figure  10.  The  ADNS  program 
office  has  established  a  lab  located  in  building  660  at  the  Space  and  Naval  Warfare 
Systems  Command  (SPA WAR)  Systems  Center  -  San  Diego  (SSC-SD).  The  lab  has 
been  designed  mainly  for  testing  and  validation  of  the  CAPs.  To  avoid  the  added 
expense  and  labor  of  duplicating  these  facilities  at  NPS,  the  SSC-SD  ADNS  lab  was  used 
to  provide  access  to  UHF  DAMA  SATCOM.  The  ADNS  lab  also  has  the  capability  to 
access  SHF  and  EHF  satellites  via  the  appropriate  CAPs.  The  normal  configuration  for  a 
UHF  DAMA  SATCOM  data  connection  is  from  the  ship  to  a  regional  Naval  Computer 
and  Telecommunications  Master  Station  (NCTAMS)  where  the  information  can  be  sent 
forward  via  a  terrestrial  SIPRNET  connection.  This  is  the  type  of  configuration  used  for 
our  test,  with  the  ADNS  lab  simulating  a  NCTAMS.  This  was  accomplished  by  setting 
up  both  ends  of  the  UHF  DAMA  SATCOM  link  (one  which  would  typically  be  aboard  a 
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ship,  and  the  other  at  the  NCTAMS)  and  routing  data  to  the  SIPRNET  as  shown  in  Figure 
11. 
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Figure  10  GBS  Reach  Back  Test  Configuration 

One  of  the  main  challenges  faced  in  setting  up  this  test  concerned  the  routing  of 
the  reach  back  requests  through  the  SIPRNET.  Specifically,  it  was  necessary  to  force  the 
reach  back  request  to  go  through  the  UHF  DAMA  CAP  located  at  the  ADNS  lab  and 
ensure  the  retransmit  request  acknowledgments  from  the  gateway  computer  (at  the  JIMC) 
came  back  along  the  same  path  (i.e.,  through  the  ADNS  lab  and  the  UHF  DAMA 
SATCOM  circuit)  rather  than  some  other  SIPRNET  path  to  the  NPS  RDM.  If  no  special 
action  were  taken,  when  the  GBS  operator  at  NPS  made  a  reach  back  request,  the  IP 
packet  would  show  the  NPS  IP  address  as  the  source  and  the  GBS  gateway  IP  address  as 
the  destination.  Assuming  we  could  statically  route  the  request  through  the  UHF  DAMA 
channel  (which  would  be  a  challenge  in  itself  with  all  of  the  intermediate  routers  in  the 
path),  the  problem  remains  as  how  to  ensure  the  reply  from  the  GBS  gateway  does  not 
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come  directly  back  through  the  SIPRNET  to  NPS  and  skip  the  UHF  DAMA  channel 
entirely. 

1.  Tunnel  Connection 

The  solution  involved  setting  up  a  KAQ9  Network  Operating  System  (NOS) 
tunnel  between  two  Cisco  routers,  one  located  at  NPS  and  one  located  at  SSC.  (See 
Figure  11.)  In  addition  to  the  tunnel,  an  IP  address  from  the  ADNS  lab  subnet  was 
assigned  to  the  GBS  RDM.  As  far  as  the  computers  were  concerned,  the  use  of  an  ADNS 
IP  address  allowed  the  NPS  RDM  in  Monterey  to  "look  like"  it  was  physically  located  at 
SSC  in  San  Diego. 

The  KAQ9  NOS  tunnel  is  a  selectable  mode  of  operation  on  the  Cisco  routers 
which  allows  discontinguous  sections  of  a  Local  Area  Network  (LAN)  to  be  connected. 
The  protocol  is  based  on  the  KAQ9  NOS  packet  radio  protocol  for  TCP/IP.  Each  end  of 
the  tunnel  has  a  specific  IP  address  as  shown  in  Figure  1 1 .  The  tunnel  encapsulates  the 
IP  datagram  with  a  destination  address  of  the  other  end  of  the  tunnel.  Once  the  datagram 
reaches  the  other  end  of  the  tunnel  it  is  unwrapped  and  sent  out  in  the  normal  manner.  To 
the  computers  connected  at  each  end  of  the  tunnel  it  looks  as  if  the  other  section  of  the 
LAN  is  only  one  router  hop  away,  while  in  fact  it  may  be  many  hops  away.  (In  our  case 
there  were  approximately  six  hops  from  NPS  to  the  SSC  ADNS  lab  without  the  tunnel.) 
The  tunnel  interface  display  is  shown  in  Figure  12.  The  important  fields  are  described 
below  the  figure. 
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Figure  1 1  Tunneling  Setup 

Referring  to  Figure  1 1,  the  signal  flow  is  as  follows: 

•  The  GBS  RDM  operator  makes  a  request 

•  The  packet  is  sent  through  the  tunnel  to  the  ADNS  Cisco  router  #1 

•  The  ADNS  Cisco  router  #1   static  routes  anything  destined  to  the  GBS 
Gateway  via  UHF  DAMA 
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•  The  GBS  Gateway  acknowledges  the  packet  and  replies  to  the  GBS  RDM 
(whose  address  is  a  part  of  the  SSC  subnet) 

•  The  reply  is  static  routed  back  through  the  UHF  DAMA  channel  by  the  ADNS 
Cisco  Router  #2 

•  After  the  reply  is  received  it  is  sent  by  the  ADNS  Cisco  router  #1  via  the  NOS 
tunnel  to  the  NPS  RDM 


1 .  nps#show  interface  tunnel  0 

2.  TunnelO  is  up,  line  protocol  is  up 

3.  Hardware  is  Routing  Tunnel 

4.  Internet  address  is  140.199.199.97,  subnet  mask  is  255.255.255.248 

5.  MTU  1500  bytes,  BW  9  Kbit,  DLY  500000  usee,  rely  255/255,  load  1/255 

6.  Encapsulation  TUNNEL,  loopback  not  set,  keepalive  set  (10  sec) 

7.  Tunnel  source  207.85.236.1,  destination  192.84.124.36 

8.  Tunnel  protocol/transport  KA9Q-NOS/IP,  key  disabled,  sequencing  disabled 

9.  Checksumming  of  packets  disabled 

10.  Last  input  2w6d,  output  0:00:04,  output  hang  never 

1 1 .  Last  clearing  of  "show  interface"  counters  4w5d 

12.  Output  queue  0/0,  0  drops;  input  queue  0/75,  0  drops 

13.  5  minute  input  rate  0  bits/sec,  0  packets/sec 

14.  5  minute  output  rate  0  bits/sec,  0  packets/sec 

15.  82700  packets  input,  5287830  bytes,  0  no  buffer 

16.  Received  0  broadcasts,  0  runts,  0  giants 

1 7.  0  input  errors,  0  CRC,  0  frame,  0  overrun,  0  ignored,  0  abort 

18.  380322  packets  output,  26048407  bytes,  0  underruns 

19.  output  errors,  0  collisions,  0  interface  resets,  0  restarts 


Figure  12  Tunnel  Interface 
Referring  to  Figure  12,  the  tunnel  statistics  of  particular  interest  are: 

•  Line  1  is  the  command  on  the  Cisco  to  view  the  tunnel  statistics. 

•  Line  4  shows  the  IP  address  of  the  NPS  end  of  the  tunnel  (this  is  the  address 
that  the  static  route  from  the  RDM  is  set  to). 
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•  Line  7  shows  the  IP  addresses  of  the  NPS  and  SSC-SD  routers  at  each  end  of 
the  tunnel. 

•  Line  8  shows  the  tunneling  protocol. 

•  Lines  1 5  and  1 8  show  the  number  of  packets  input  to  the  tunnel  and  number  of 
packets  output  from  the  tunnel  respectively.  Clearing  the  counters  and  using 
the  ping  utility  allowed  us  to  determine  if  the  packets  were  being  routed 
properly.  Ping  would  send  a  fixed  number  of  packets  to  a  destination  IP 
address  and  then  we  could  look  at  the  counter  and  determine  if  they  had 
actually  been  routed  through  the  tunnel. 

C.         DATA  COLLECTION 

The  purpose  of  the  data  collection  was  to  evaluate  the  effectiveness  of  the  ADNS 
CAP  and  UHF  DAM  A  SATCOM  as  a  reach  back  channel  for  the  GBS  Phase  One 
system,  and  then  interpret  the  data  as  they  apply  to  GBS  Phase  Two.  As  discussed  in 
Chapter  I,  this  experiment  would  be  impossible  without  a  CAP  or  some  other  protocol 
which  handles  the  timing  and  interface  requirements  to  transmit  TCP/IP  over  UHF 
DAMA.  The  majority  of  the  data  collection  involves  the  use  of  the  UNIX  command 
snoop  which  allows  us  to  monitor  and  time  tag  all  activity  taking  place  on  a  specific 
network  device.  A  sample  session  and  labels  for  the  columns  are  shown  in  Table  3.  To 
save  space,  some  of  the  additional  information  normally  found  in  the  snoop  output  has 
been  deleted.  The  column  headings  are  explained  below  the  table. 
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The  NPS  RDM  has  two  network  devices;  leO  which  is  connected  directly  to  the 
GBS  Cisco  router,  and  lei  which  is  connected  to  the  SIPRNET  (as  shown  in  Figure  9). 
Snoop  must  be  run  while  logged  in  with  root  privileges.  The  command  line  entry  is 
%snoop  -d  lei  -tr  hostname.  The  -d  lei  option  allows  us  to  filter  packets  only  on  the  lei 
network  device.  The  -tr  option  time  stamps  all  packets  received  relative  to  the  first 
packet  with  an  accuracy  of  +/-  4  microseconds.  The  hostname  option  allows  some 
additional  filtering  so  that  only  packets  addressed  to  or  from  the  specified  hostname  will 
be  displayed.  [Ref.  19] 


Time 

Prig 

Desl 

Type 

Pest 

Port 

Source 
Port 

Special 

Sequence  Number 

Data 

0.000 

daffey  > 

GBS  GATEWA 
Y 

TCP 

D=80 

S=32966 

Syn 

Seq=3 178448483 

Len=0 

Table  3  Sample  Snoop  Line 

•  Time  -  relative  time  since  last  event 

•  Orig  -  originating  computer  (daffey  is  an  alias  for  the  RDM) 

•  Dest  -  destination  computer 

•  Type  -  type  of  connection  e.g.  FTP,  TCP... 

•  Dest  Port  -  Destination  port 

•  Source  port 

•  Special  -  in  this  case  SYN  is  used  when  establishing  a  TCP  session,  usually 
blank 
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•  Sequence  Number  of  packet 

•  Data  -  Number  of  bytes  of  data  contained  in  packet 

Snoop  was  the  primary  tool  used  to  collect  data  during  all  of  the  reach  back  trials. 
The  data  collection  and  results  are  described  in  the  following  chapter. 

D.         ADNS  CAP  LOADING 

The  test  was  conducted  with  the  RDM  directly  connected  to  the  SIPRNET  and 
under  varying  loads  on  the  GBS  reach  back  UHF  DAMA  SATCOM  channel.  The  loads 
on  the  back  channel  were: 

•  Two  users  (each  is  Vi  of  a  full  duplex  link) 

•  Four  users  no  load 


•      Four  users  25%  load 


•      Four  users  50%  load 

The  loads  were  defined  as  follows.   A  four  user  frame  with  a  25%  load  is  shown 
in  Figure  13.  Each  user  is  allowed  up  to  eight  frames  of  data,  therefore  a  25%  load  would 


19.41  Sec                                                                                    I 

1.3866S 

....                  ^. 

*                ^ 

1 

1 

■  ■  ■  ■ 

* 

* 

> 

Userl                                                           User  4                                       Add 

Figure  1 3  Four  User  ADNS  Frame 
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utilize  two  of  the  eight  frames.  The  load  determines  the  minimum  response  time  of  the 
link.  If  there  is  only  one  user  with  one  data  frame  (not  a  very  efficient  use  of  the  link) 
ADNS  would  use  four  DAMA  frames  and  the  total  ADNS  frame  length  could  be  as  short 
as  5.5  seconds.  As  mentioned  in  Chapter  II,  when  fully  loaded  (four  users  each  with  8 
frames  of  data)  the  link  cycle  time  is  52.69  seconds. 

E.         EXPERIMENT  SETUP  SUMMARY 

With  all  of  the  equipment  properly  configured,  the  routing  problems  solved,  and 
the  data  collection  plan  in  place,  all  that  remained  was  to  run  the  tests.  The  tests  were 
conducted  6-17  April  1998  utilizing  the  Phase  One  GBS  secret  IP  channel.  The  specific 
results  are  discussed  in  the  next  chapter.  The  tunnel  remains  active  although  the  default 
route  has  been  removed  to  facilitate  future  testing. 
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IV.       TEST  RESULTS 

A.         DISCUSSION 

Tests  were  conducted  varying  the  UHF  DAMA  channel  loading  and  number  of 
users  parameters  discussed  in  the  previous  chapter.  Each  configuration  was  tested  until 
there  were  ten  successful  reach  back  sessions  or  until  it  became  obvious  that  the  link  was 
not  going  to  work.  One  of  the  key  points  that  became  obvious  early  on  as  we  began  to 
add  additional  users  and  traffic  was  that  the  TCP  session  would  be  closed  by  the  RDM  if 
it  had  not  received  an  acknowledgment  to  its  SYN  packet  (the  beginning  of  the  three-way 
handshake)  from  the  GBS  gateway  within  30  seconds.  An  example  of  a  failed  session  is 
shown  in  Figure  14.  This  particular  example  is  from  a  test  with  four  users  and  a  25% 
load.  The  only  differences  between  Figure  14  and  the  explanation  of  the  snoop  display  in 
the  previous  chapter  are  the  RST  in  line  4  which  indicates  the  connection  has  been  closed 
out  since  there  was  no  response  within  30  seconds  and  the  ACK  field  in  line  5  (which  is 
the  acknowledgment  of  a  packet  from  the  destination  computer).  Once  a  session  had 
been  established  (the  three-way  handshake  completed),  it  was  satisfactory  if  the 
subsequent  acknowledgments  took  longer  than  30  seconds,  and  several  did.  Timely 
acknowledgment  of  the  initial  SYN  packet  was  the  critical  factor. 


1  0.00000  daffey  ->  GBSGATEWAY  TCP  D=80  S=32966  Syn  Seq=3 1 78448483  Len=0 

2  4.73776  daffey  ->  GBS_GATEWAY  TCP  D=80  S=32966  Syn  Seq=3 1 78448483  Len=0 

3  14.20794  daffey  ->  GBS_GATEWAY  TCP  D=80  S=32966  Syn  Seq=3 1 78448483  Len=0 

4  29.99909  daffey  ->  GBS_GATEWAY  TCP  D=80  S=32966  Rst  Seq=3 1 78448484  Len=0 

5  3 1 .34264  GBSJjATEWAY  ->  daffey  TCP  D=32966  S=80  Syn  Ack=3 1 78448484  Seq=  1 548 1 24364  len=0 

6  3 1 .34279  daffey  ->  GBS_GATEW AY  TCP  D=80  S=32966  Rst  Seq=3 1 78448484  Len=0 


Figure  14  Failed  Reach  back  Session 
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The  GBS  RDM  operating  system  -  Sun  Solaris  2.5.1  has  a  utility  called  'ndd' 
which  allows  manipulation  of  the  TCP/IP  driver  configuration  parameters.  These 
configurable  parameters  can  be  viewed  by  typing  the  command  %ndd  /dev/tcp  \?.  The 
names  of  the  parameters  are  somewhat  self  explanatory,  e.g. 
TCPCONNABORTTHRESHOLD.  I  was  able  to  vary  how  long  the  RDM  waits  to 
retransmit  a  packet.  Unfortunately,  I  was  unable  to  have  any  impact  on  the  problem  of 
the  driver  resetting  the  connection  if  it  had  not  received  the  SYN  ACK  within  30  seconds. 

B.         OBSERVATIONS 

During  the  initial  test  setup  we  were  unable  to  establish  the  tunnel  connection 
between  NPS  and  SSC.  The  difficulty  turned  out  to  be  the  SSC  firewall  which  was 
blocking  our  connection.  After  discussing  our  test  with  the  appropriate  security 
personnel,  we  were  able  to  get  access  through  the  firewall  and  complete  the  tunnel. 

When  we  first  switched  from  a  direct  SIPRNET  connection  to  using  the  UHF 
DAMA  back  channel,  there  were  a  large  number  of  Internet  Control  Message  Protocol 
(ICMP)  messages  being  sent  over  the  link.  The  GBS  RDM  would  send  an  ICMP 
message  every  few  seconds  until  it  got  a  response;  this  occurred  approximately  every 
thirty  seconds.  The  RDM  would  send  about  ten  packets  until  the  first  response  was 
received.  After  some  investigation  it  was  determined  that  the  xferit  script  (running  on  the 
RDM)  was  the  culprit.  Xferit  is  the  process  that  transfers  wrapped  information  product 
files  to  the  GBS  gateway  for  broadcast.  If  a  RDM  was  setup  to  allow  users  to  wrap  files, 
the  process  would  check  the  link  to  the  GBS  gateway  every  30  seconds  and  then  check 
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the  outgoing  wrapped  directory  to  see  if  there  were  any  files  to  upload.  A  quick  fix  from 
Welkin  &  Associates  changed  the  script  so  it  checked  the  outgoing  wrapped  directory 
first,  and  then  checked  to  see  if  the  GBS  gateway  was  reachable.  Therefore  the  ICMP 
messages  would  only  be  sent  when  there  were  files  to  upload.  This  eliminated  the  extra 
traffic  on  our  high  latency,  bandwidth  restricted  reach  back  channel. 

When  directly  connected  to  the  SIPRNET  (i.e.,  not  via  the  UHF  satellite)  the 
reach  back  session  took  approximately  1.35  seconds  to  complete.  The  requested  file 
consistently  showed  up  on  the  broadcast  1  to  2  minutes  after  the  request.  When  using 
UHF  DAMA  as  the  reach  back  channel,  the  requested  file  would  often  arrive  before  the 
user  pull  TCP/IP  session  had  actually  completed.  This  was  due  to  the  fact  the  TCP/IP 
session  took  so  long  to  complete  (see  Table  4).  The  GBS  gateway  would  have  all  of  the 
information  it  needed  to  queue  up  the  file  before  all  of  the  handshaking  was  completed  to 
close  out  the  TCP/IP  reach  back  session.  As  discussed  in  Chapter  I,  some  of  the  previous 
reach  back  experiments  have  experienced  wide  ranges  in  file  delivery  time.  This  has 
been  attributed  to  the  queuing  at  the  JIMC  GBS  Gateway.  This  effect  was  not  observed 
during  the  experiments  conducted  for  this  thesis.  The  amount  of  traffic  at  the  uplink 
facility  did  not  seem  to  have  an  appreciable  impact  on  file  delivery  times.  The  testing 
was  conducted  over  a  two- week  period  and  traffic  on  the  Phase  One  GBS  IP  data  channel 
ranged  from  none  up  to  2  Mbps  (the  channel  allocation  is  4  Mbps).  Different  files  were 
requested  each  time,  and  their  sizes  ranged  from  approximately  100  kilobytes  up  to  5 
megabytes. 
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C.         SUCCESSFUL  REACH  BACK  SESSION 

An  example  of  a  successful  reach  back  session  is  shown  in  Figure  15.  The  line 
numbers  have  been  added  to  facilitate  discussion  of  what  is  actually  occurring  in  the 
session. 

•  Lines  1-3  are  the  initial  SYN  packet  and  the  retransmission  due  to  time-outs. 
Three  SYNs  were  sent  before  a  response  was  received  from  the  GBS  Gateway. 

•  Line  4  is  the  acknowledgment  from  the  GBS  gateway,  (this  one  made  it  with 
less  than  0.2  seconds  to  spare  before  the  session  would  have  timed  out) 

•  Line  5  is  the  ACK  from  the  GBS  RDM  that  completes  the  three-way 
handshake  to  establish  a  TCP/IP  connection. 

•  Lines  6-1 1  are  the  initial  transmission  and  time-out  retransmissions  of  the  first 
data  packet.  Notice  the  packet  contains  1 64  bytes  of  data,  this  was  consistent 
for  all  of  the  reach  back  sessions.  The  time  between  successive  transmissions 
is  approximately  0.5,  1,  2,  4,  and  8  seconds.  This  is  the  TCP/IP  exponential 
back-off  algorithm  where  if  an  ACK  is  not  received  the  time  to  retransmit  is 
doubled  up  to  a  maximum  64  seconds  typically.  [Ref.  8] 

•  Line  12  is  the  acknowledgment  of  the  first  data  packet.  It  can  be  seen  the 
acknowledgment  takes  over  30  seconds  yet  the  connection  is  not  reset.  This  is 
because  once  the  TCP  connection  is  established,  a  (different)  timer  is  used  that 
takes  into  account  the  round  trip  time  of  a  connection.  [Ref.  8] 
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1  0.00000  daffey  ->  GBS_GATEWAY  TCP  D=80  S=33291  Syn  Seq=l 503463643  Len=0 

2  4.73658  daffey  ->  GBS_GATEWAY  TCP  D=80  S=33291  Syn  Seq=l  503463643  Len=0 

3  14.20666  daffey  ->  GBS_GATEWAY  TCP  D=80  S=33291  Syn  Seq=  1503463643  Len=0 

4  29.83600  GBS_GATEWAY  ->  daffey  TCP  D=33291  S=80  Syn  Ack=l 503463644  Seq=154141740  Len=0 

5  29.83619  daffey  ->  GBSGATEWAY  TCP  D=80  S=33291      Ack=154141741  Seq=  1503463644  Len=0 

6  29.88020  daffey  ->  GBS_GATEWAY  TCP  D=80  S=33291  Ack=l  54141 741  Seq=l  503463644  Len=164 
30.35641  daffey  ->  GBS_GATEWAY  TCP  D=80  S=33291  Ack=154141741  Seq=  1503463644  Len=164 
31.32370  daffey  ->  GBS_GATEWAY  TCP  D=80  S=33291      Ack=l  5414 1741  Seq=  1503463644  Len=164 

9  33.23655  daffey  ->  GBSJ3ATEWAY  TCP  D=80  S=33291      Ack=154141741  Seq=l 503463644  Len=164 

10  37.07651  daffey  ->  GBS_GATEWAY  TCP  D=80  S=33291      Ack=154I41741  Seq=  1503463644  Len=164 

1 1  44.75648  daffey  ->  GBS_GATEWAY  TCP  D=80  S=33291      Ack=154141741  Seq=  1503463644  Len=164 

12  59.04906  GBS_GATEWAY  ->  daffey  TCP  D=33291  S=80      Ack=l  503463808  Seq=154141741  Len=0 

13  59.04924  daffey  ->  GBSJ3ATEWAY  TCP  D=80  S=33291      Ack=154141741  Seq=l 503463808  Len=33 

14  59.52643  daffey  ->  GBS_GATEWAY  TCP  D=80  S=33291      Ack=154141741  Seq=l 503463808  Len=33 

15  60.48656  daffey  ->  GBS_GATEWAY  TCP  D=80  S=33291      Ack=154141741  Seq=l 503463808  Len=33 

16  62.40657  daffey  ->  GBSJ3ATEWAY  TCP  D=80  S=33291      Ack=154141741  Seq=l 503463808  Len=33 

17  66.24642  daffey  ->  GBS_GATEWAY  TCP  D=80  S=33291      Ack=154141741  Seq=l 503463808  Len=33 

18  73.92655  daffey  ->  GBS_GATEWAY  TCP  D=80  S=33291      Ack=154141741  Seq=l  503463808  Len=33 

19  85.37959  GBS_GATEWAY  ->  daffey  TCP  D=33291  S=80      Ack=l 503463841  Seq=l  54141741  Len=0 

20  85.39577  GBSGATEW  AY  ->  daffey  TCP  D=33291  S=80      Ack=l  503463841  Seq=l  54 14 1741  Len=31 

21  85.40890  GBSJ3ATEWAY  ->  daffey  TCP  EK53291  S=80      Ack=1503463841  Seq=154141772  Len=37 

22  85.40902  daffey  ->  GBS_GATEWAY  TCP  D=80  S=33291      Ack=154141809  Seq=  15 03463 841  Len=0 

23  102.49492  GBS_GATEWAY  ->  daffey  TCP  D=33291  S=80     Ack=1503463841  Seq=154141809  Len=20 

24  102.50556  GBSJ3ATEW AY ->  daffey  TCP  D=33291  S=80      Ack=1503463841  Seq=154141829  Len=25 

25  102.50567  daffey ->  GBS_GATEWAY  TCPD=80  S=33291      Ack=154141854  Seq=l  503463841  Len=0 

26  102.51222  GBSJ3ATEWAY  ->  daffey  TCP  D=33291  S=80      Ack=  1503463 841  Seq=154141854  Len=2 

27  102.53765  GBS_GATEWAY  ->  daffey  TCP  D=33291  S=80     Ack=l  503463841  Seq=154141856  Len=77 

28  102.53777  daffey  ->  GBS_GATEWAY  TCP  D=80  S=33291      Ack=154141933  Seq=l 503463841  Len=0 

29  102.56203  GBS_GATEWAY  ->  daffey  TCP  D=33291  S=80  Fin  Ack=l  503463841  Seq=154141933  Len=0 

30  102.56215  daffey  ->  GBS_GATEWAY  TCP  D=80  S=33291      Ack=154141934  Seq=l  503463841  Len=0 

31  102.56273  daffey  ->  GBSJ3ATEWAY  TCP  D=80  S=33291  Fin  Ack=154141934  Seq=l  503463841  Len=0 

32  102.62790  GBS_GATEWAY  ->  daffey  TCP  D=33291  S=80  Fin  Ack=  1503463841  Seq=154141741  Len=192 

33  102.62804  daffey ->GBS_GATEW AY  TCP  D=80  S=33291      Ack=154141934  Seq=l 503463842  Len=0 

34  103.03647  daffey  ->  GBS_GATEWAY  TCP  D=80  S=33291  Fin  Ack=154141934  Seq=  1503463841  Len=0 

35  103.99670  daffey  ->  GBSJjATEWAY  TCP  D=80  S=33291  Fin  Ack=154141934  Seq=  1503463841  Len=0 

36  105.91640  daffey  ->  GBS_GATEWAY  TCP  D=80  S=33291  Fin  Ack=154141934  Seq=  1503463841  Len=0 

37  109.75649  daffey  ->  GBS_GATEWAY  TCP  D=80  S=33291  Fin  Ack=154141934  Seq=  1503463841  Len=0 

38  1 17.43644  daffey  ->  GBS_GATEWAY  TCP  D=80  S=33291  Fin  Ack=154141934  Seq=l  503463841  Len=0 

39  1 18.43854  GBS_GATEWAY  ->  daffey  TCP  D=33291  S=80  Fin  Ack=l  503463841  Seq=154141809  Len=124 

40  11 8.43866  daffey ->GBS_GATEW AY  TCPD=80  S=33291      Ack=154141934  Seq=l 503463842  Len=0 

41  132.79644  daffey  ->  GBS_GATEWAY  TCP  D=80  S=33291  Fin  Ack=154141934  Seq=1503463841  Len=0 

42  134.75847  GBS_GATEWAY  ->  daffey  TCP  D=33291  S=80  Fin  Ack=  1503463 841  Seq=154141854  Len=79 

43  134.75862  daffey  ->  GBS_GATEW AY  TCP  D=80  S=33291      Ack=154141934  Seq=l 503463842  Len=0 
44 134.76293  GBS_GATEWAY  ->  daffey  TCP  D=33291  S=80      Ack=  1503463842  Seq=154141934  Len=0 

Figure  1 5  Successful  Reach  back  Session 

•  A  similar  pattern  continues  until  the  GBS  Gateway  begins  to  send  data  back  to 
the  GBS  RDM.  (Note:  These  data  are  not  the  requested  file,  but  rather  status 
information  from  the  GBS  gateway,  e.g.,  file  availability) 

•  Once  all  of  the  data  has  finished  being  transmitted  from  the  GBS  gateway  it 
sends  a  FIN  packet  on  line  29. 
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•The  GBS  RDM  acknowledges  the  FIN  (line  30)  and  sends  its  own  FIN  on  line 

31. 
•The  session  is  closed  out  once  the  GBS  RDM  receives  an  ACK  for  its  FIN 

packet  on  line  44. 
•The  additional  FIN  packets  being  exchanged  are  due  to  the  fact  that  they  were 

not  filtered  in  the  ADNS  queue. 

D.        TOTAL  TIME  TO  COMPLETE  REACH  BACK  SESSION 

Total  time,  defined  as  the  time  from  the  first  SYN  sent  from  the  RDM  until  the 
final  ACK  was  received  closing  out  the  TCP  session,  was  chosen  since  it  represents  the 
entire  time  that  the  UHF  DAMA  channel  was  occupied  and  not  available  to  other  users. 
The  total  time  for  the  session  to  complete  turned  out  to  be  directly  related  to  the  amount 
of  traffic  and  the  number  of  users.  This  makes  sense  since  more  users  and  more  data 
expand  the  total  time  for  an  ADNS  frame.  The  summary  results  are  shown  in  Table  4. 
The  reason  none  of  the  50%  load  attempts  were  successful  is  explained  in  Section  E. 


Direct 
Connect 

Two  Users 

Four  Users 
No  Load 

Four  Users 
25%  Load 

Four  Users 
50%  Load 

Attempts  / 
Successful 

10/10 

10/10 

10/10 

10/13 

0/14 

Percent 
Successful 

100% 

100% 

100% 

76.9% 

0% 

Mean  Time 

1.356 

78.76 

79.31 

112.01 

NA 

Std  Dev 

0.079 

2.95 

3.21 

5.58 

NA 

Table  4  Total  Time  to  Complete  Reach  Back 
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There  is  not  a  large  difference  between  the  two  user  configuration  and  the  four 
user  no  load  configuration.  This  is  because  the  version  of  ADNS  software  that  was  used 
removes  members  from  the  net  if  they  have  not  sent  data  recently.  Therefore  the  two 
users  who  were  not  active  participants  in  the  four  user  net  were  removed  after  a  period  of 
inactivity.  If  there  was  no  activity  within  ten  cycles  the  user  was  dropped. 

E.         TIME  TO  FIRST  ACK 

The  critical  factor  influencing  the  number  of  successful  attempts  in  Table  4  was 
the  time  elapsed  before  acknowledgment  of  the  SYN  sent  by  the  RDM.  The  actual 
response  time  for  the  SYN  ACK  is  shown  in  Table  5.  None  of  the  four  user  50%  load 
tests  were  successful  since  the  average  response  time  did  not  come  close  to  the  required 
30  seconds.  The  four  user  25%  load  result  really  depended  on  where  the  ADNS  frame 
was  at  in  its  cycle  when  the  request  hit  it.  For  example,  if  the  GBS  user  was  ADNS  user 
one  and  if  user  one's  time  slot  had  just  passed  when  the  request  hit  the  CAP  queue,  it 
would  have  to  wait  one  whole  cycle  until  it  went  out.  The  ACK  would  then  take  up  to 
almost  two  cycles  to  get  back. 


Direct 
Connect 

One  User 

Four  User  No 
Load 

Four  User  25% 
Load 

Four  User 
50%  Load 

Mean  Time 

.260 

16.62 

17.24 

26.77 

41.32 

Std  Dev 

.023 

2.51 

0.92 

5.07 

4.87 

Table  5  Average  Time  to  First  ACK 
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F.         TEST  RESULTS  SUMMARY 

The  results  of  the  testing  identified  limitations  of  the  ADNS  CAP  interface  for  the 
use  of  UHF  DAMA  SATCOM  as  a  reach  back  channel  for  GBS.  If  the  CAP  has  a  round 
trip  cycle  time  of  greater  than  thirty  seconds,  then  GBS  reach  back  with  this  set  of 
TCP/IP  parameters  will  not  work.  The  testing  reported  here  actually  has  application  to 
TCP/IP  data  connections  in  general.  As  shown  here,  the  choice  of  computer  operating 
system  has  a  direct  impact  because  the  TCP/IP  parameters  vary  with  operating  system. 
The  implications  of  this  testing  for  the  GBS  Phase  Two  systems,  and  recommendations 
for  further  research  are  discussed  in  the  following  chapter. 
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V.         CONCLUSION 

A.  APPLICATION  TO  GBS  PHASE  TWO 

This  experiment  was  performed  using  the  GBS  Phase  One  Testbed  and  the  GBS 

Phase  One  Receive  Suite.  The  GBS  Phase  One  receive  suite  is  based  on  the  UNIX 
operating  system,  while  the  GBS  Phase  Two  systems  will  be  based  on  Microsoft 
Windows  NT.  What  is  the  relevance  of  this  experiment  to  the  GBS  Phase  Two  system? 
This  chapter  will  address  that  question,  discuss  the  application  of  this  testing  to  5-kHz 
UHF  DAMA  SATCOM,  and  recommend  future  areas  for  thesis  research. 

B.  GBS  PHASE  TWO  SYSTEMS 

If  one  of  the  goals  of  the  GBS  program  is  to  integrate  their  system  into  existing 
communications  architectures  in  a  seamless  manner,  then  design  configurations  must  take 
into  account  legacy  military  system  specifications.  The  goal  of  GBS  to  use  commercial 
off  the  shelf  (COTS)  solutions  is  admirable,  but  there  are  existing  military  systems  which 
may  hamper  the  use  of  COTS  solutions. 

UHF  DAMA  SATCOM  was  developed  to  add  flexibility  to  the  existing  UHF 
SATCOM  infrastructure.  The  decision  to  adopt  DAMA  as  the  "protocol  of  the  future" 
for  UHF  SATCOM  was  made  before  the  explosion  of  TCP/IP  based  Internet  digital 
communications  such  as  the  World  Wide  Web,  Email,  Telnet  and  File  Transfer  Protocol 
(FTP).  With  hindsight,  the  UHF  SATCOM  DAMA  protocols  might  have  been  developed 
differently  to  enhance  support  of  data  communications.   The  result  of  a  long  acquisition 
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process  and  slow  fielding  of  UHF  DAMA  has  resulted  in  commercial  technology 
eclipsing  military  capabilities  again.  COTS  -  based  programs  such  as  GBS  must  ensure 
that  the  drive  to  adopt  COTS  solutions  takes  into  account  legacy  military  system 
requirements. 

The  GBS  Phase  Two  RBM  must  have  the  capability  and  flexibility  to  interface 
with  systems  ranging  from 

•  Hardwired  SIPRNET  Connection  -  variable  bandwidth,  low  latency 

•  Dial  Up  Connection  -  (STU-III,  1200-9600  bps) 

•  SHF  SATCOM  -  high  bandwidth,  relatively  low  latency 

•  EHF  SATCOM  -  limited  bandwidth,  relatively  low  latency 

•  UHF  DAMA  SATCOM  -  limited  bandwidth,  high  latency 

•  And  other  systems  such  as  the  Army's  Mobile  Subscriber  Equipment... 

What  will  provide  this  flexible  capability?  At  a  minimum,  the  systems  should 
have  the  capability  to  adjust  the  TCP/IP  connection  parameters,  or  at  least  have  different 
"standard"  configurations  which  allow  the  system  to  take  into  account  variable  reach 
back  communications  methods.  This  capability  would  eliminate  the  problems  identified 
in  Chapter  IV.  It  will  not  solve  the  high  latency  problems  because  they  are  an  artifact  of 
the  channel  being  utilized,  but  at  least  the  comiection  would  work. 

C.         25  KHZ  UHF  DAMA  VERSUS  5  KHZ  UHF  DAMA 

The  equipment  used  for  this  test  limited  us  to  the  use  of  25-kHz  UHF  DAMA 
SATCOM.  The  TD-1271  multiplexer  and  the  AN/WSC-3  UHF  transmitter  are  designed 
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to  work  only  with  25-kHz  DAMA.  This  test  would  be  practically  impossible  to  repeat 
using  a  protocol  like  the  ADNS  CAP  and  5 -kHz  DAMA  because  of  its  longer  frame 
length  (8.96  seconds  versus  1.3866  seconds).  In  addition,  the  ADNS  approach  of  time 
sharing  a  small  portion  of  the  channel  would  only  increase  the  framing  delays  by 
overlaying  its  own  set  of  delays.  This  is  where  an  interface  such  as  the  ADC/IP  discussed 
previously  might  help.  As  mentioned,  the  ADC/IP  is  operated  in  the  DASA  mode  and 
access  to  the  channel  is  governed  by  the  CSMA  protocol.  This  is  a  logical  approach  for 
this  type  of  channel  and  it  minimizes  the  channel  access  times  (which  is  important  with 
the  large  framing  delays). 

Nonetheless,  there  are  two  drawbacks  to  the  ADC/IP  approach.  First,  the 
efficiency  of  a  CSMA  system  is  dependent  on  the  size  of  the  data  frames  and  the  total 
propagation  time  of  the  link.  [Ref.  20,  Chapter  13]  For  UHF  DAMA  SATCOM  the 
protocol  framing  delays  and  satellite  round  trip  delay  combine  to  increase  the  propagation 
time,  therefore  decreasing  the  maximum  utilization  of  the  link.  The  second  problem  is 
implementation-related  and  that  is  the  paucity  of  UHF  DAMA  channels  to  provide 
dedicated  data  service.  Recall  that  DASA  channels  cannot  be  preempted. 

In  my  opinion,  the  best  solution  is  to  try  to  piggyback  any  GBS  reach  back  onto 
existing  communications  channels.  The  probability  of  having  a  UHF  DAMA  SATCOM 
channel  dedicated  for  such  a  low  duty  cycle  connection  is  extremely  small.  This  is  the 
mode  of  operation  I  would  expect  for  a  system  using  ADNS  and  in  particular  the  ADNS 
UHF  DAMA  CAP. 


49 


D.         RECOMMENDATIONS  FOR  FUTURE  RESEARCH 

As  discussed  in  Chapter  II,  the  GBS  Phase  Two  receive  suite  RBM  will  use  email 
and  PPTP  as  the  initial  reach  back  communications  method.  The  NPS  GBS  Test  Bed  has 
a  Windows  NT  machine  on  the  same  local  area  network  (LAN)  as  the  GBS  RDM.  The 
SSC-SD  ADNS  lab  has  an  NT  server  on  the  same  LAN  as  the  ADNS  CAPs.  We  are  in 
the  process  of  establishing  a  PPTP  tunnel  between  the  two  computers  and  will  perform  a 
similar  test,  only  with  the  routing  being  handled  by  the  PPTP  connection  rather  that  the 
NOS  tunnel.  Of  particular  interest  will  be  the  additional  overhead  added  by  PPTP.  The 
test  setup  is  shown  in  Figure  16.  The  plan  is  to  present  the  results  of  the  PPTP  testing  in 


Dashed  Line 

represents  PPTP 

connection  through 

SIPRNET  and  UHF 

DAMA  SATCOM 


OBS  Receive  Data 

Manager  (RDM) 

75  MHz  Processor. 

128  MB  RAM.  8  GB 

Hard  Drive  Sotana  2  5 


GBS  RDM  static 

routed  to  IP  address 

of  PPTP  tunnel  on 

NT  Client 


Details  Omitted 


Microsoft  NT  Server 


Figure  16  PPTP  Tunnel 
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a  paper  at  MILCOM  1998. 

Additionally,  experiments  involving  other  protocol/systems  which  interface 
computer  communications  with  UHF  DAMA  would  be  useful.  For  example,  the  ADC/IP 
and  AN/PSC-5  UHF  DAMA  System. 

E.         SUMMARY 

This  thesis  has  demonstrated  that  GBS  reach  back  via  UHF  DAMA  SATCOM  is 
indeed  a  viable  option.  The  actual  implementation  of  such  a  capability  relies  on  factors 
such  as  the  GBS  Phase  Two  receive  suites,  access  to  a  UHF  DAMA  channel,  and  for  non- 
ADNS  users,  a  protocol  to  access  the  channel  that  allows  it  to  support  TCP/IP 
communications. 
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APPENDIX  A  GBS  PRODUCTS 

[Ref.  1] 


Information  Product 

Data 

Class 

Pt.  Of  Origin 

SBM 

End  User 
HW/SW  Rqmts 

Data 

A/V 

Source 

1 

MAPPING,  CHARTING  AND 
GEODESY  ((GGIS)) 

X 

s 

NIMA  -St.  Louis 

SIPRNET 

Browser  Applications 

2 

METEOROLOGICAL  AND 
OCEANOGRAPH1C  (METOC) 

X 

s 

NPMOC 

SIPRNET 

Browser,  MPEG  viewer 

3 

ARMY  NOTICES  OF 
AMMUNITION 
RECLASSIFICATION  (NARS) 

X 

U 

HQ,  JOC 

AUTODIN 

AMHS 

4 

MISSILE  NOTICE  OF 
AMMUNITION 
RECLASSIFICATION  (NARS) 

X 

U 

HQ,  MICOM 

AUTODIN 

AMHS 

5 

OVERHEAD  FIRE 
SUPPLEMENTAL  NOTICES 

X 

U 

HQ,  JOC 

AUTODIN 

AMHS 

6 

TPFDL 

X 

S 

CINCPAC  J3/4/5 

GCCS 

GCCSRDA 

7 

COMMON  TACTICAL  PICTURE 

X 

s 

J3  (GCCS/JMCIS) 

GCCS 

GCCS  3.0 

8 

TOMAHAWK  LND  CRUISE 
MISSILE  ATK  MSN  SUPPORT 

X 

TS 

CMSA  (CRUISE 
MISSILE  SUPPORT, 
USPACOM  AND 
USACOM) 

CP  SMITH 
B/20 

7AF=MDS ,  Ships=Fire 
Control  Sys 

9 

ATO 

X 

s 

7AF 

OSAN 

CTAPS 

10 

SOFTWARE 
UPDATES/PATCHES 

X 

TSC 

MULTIPLE 
SOURCES 

JICPAC  et  al 

? 

11 

MEDICAL  INTELLIGENCE 

X 

X 

u 

AFMIC,  WHO,  JTF 

ArMedSurvA 
cty 

WALTER  REED 

12 

GTN  (ITV,  JTAV/JTAD) 

X 

X 

u,s 

USTRANSCOM 

? 

BROWSER 

13 

SARSS-O/RF/ 

X 

? 

? 

? 

? 

14 

INTEGRATED  BROADCAST 
SERVICE  (IBS) 

X 

s 

NSA/NRO/AIA 
(JICPAC) 

UHFvia 
landline 

CTT/MATT=>JTT 

15 

USE/LOCATION  OF  WMD 

X 

s 

JTF,  JICPAC 

SIPRNET 

Browser  Applications 

16 

INTEL  IMAGERY 

X 

s 

JICPAC 

SIPRNET 

HTML,  5D,  IPL  client 

17 

DAILY  INTELLIGENCE 
BULLETIN  (DIB) 

X 

TSC 

JICPAC 

TSC  Feed 

HTML,  FrameReader, 
Adobe  Acrobat 

18 

DAILY  INTEL  SUMMARY 
(DISUM) 

X 

s 

JICPAC 

SIPRNET 

Browser  Applications 

19 

COUNTRY  FACT  SHEETS 

X 

s 

JICPAC 

SIPRNET 

HTML,  FrameReader, 
Adobe  Acrobat 

20 

DEFENSE  INTELLIGENCE 
WARNING  SYSTEM 

X 

s 

JICPAC 

SIPRNET 

Browser  Applications 

21 

HULTEC  DATABASE  MESSAGE 

X 

s 

JICPAC 

SIPRNET 

Browser  Applications 

22 

POL-MIL  AND  TACTICAL 
ADVISORIES 

X 

s 

JICPAC 

SIPRNET 

Browser  Applications 

23 

TACMILINTSUM  AND  SI- 
TACMILINTSUM 

X 

TSC 

JICPAC 

TSC  Feed 

Browser  Applications 

24 

EXPEDITIONARY  SUPPORT 
PACKAGE 

X 

s 

JICPAC 

SIPRNET 

Browser  Applications 

25 

FEASIBILITY  ASSESSMENT 
SUPPORT 

X 

s 

JICPAC 

SIPRNET 

Browser  Applications 

26 

MILITARY  CAPABILITIES 
STUDY  (MCS) 

X 

s 

JICPAC 

SIPRNET 

HTML,  FrameReader, 
Adobe  Acrobat 
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27 

JICPAC  SPECIAL  REPORT 

X 

s 

JICPAC 

SIPRNET 

HTML,  FrameReader, 
Adobe  Acrobat 

28 

TARGET  SYSTEM  ANALYSIS 

X 

s 

JICPAC 

SIPRNET 

HTML,  FrameReader, 
Adobe  Acrobat 

29 

LINES  OF  COMMUNICATIONS 
ROUTE  STUDY 

X 

s 

JICPAC 

SIPRNET 

Browser  Applications 

30 

OPERATIONAL  TARGET 
GRAPHIC  (OTG) 

X 

s 

JICPAC 

SIPRNET 

Browser  Applications 

31 

BASIC  TARGET  GRAPHIC 
(BTG) 

X 

s 

JICPAC 

SIPRNET 

Browser  Applications 

32 

QUICK  RESPONSE  GRAPHICS 
(QRG) 

X 

s 

JICPAC 

SIPRNET 

Browser  Applications 

33 

TARGET  INTELLIGENCE 
PACKAGE  (TIP) 

X 

S 

JICPAC 

SIPRNET 

Browser  Applications 

34 

IMAGERY  INTERPRETATION 
REPORT 

X 

S 

JICPAC 

SIPRNET 

Browser  Applications 

35 

MODERNIZED  INTEGRATED 
DATABASE  (M1DB) 

X 

S 

JICPAC 

SIPRNET 

Browser  Applications 

36 

CONTINGENCY 
EXPEDITIONARY/SOF 
PRODUCT  (CESP) 

X 

S 

JICPAC 

SIPRNET 

Browser  Applications 

37 

*NEO  DATABASE    *Not  listed  in 
message 

X 

S 

JICPAC 

SIPRNET 

Browser  Applications 

38 

CURRENT  INTELLIGENCE 
BRIEF 

X 

TSC 

JICPAC 

JWICS 

Monitor 

39 

J2  CHALLENGES  BRIEF 

X 

TSC 

JICPAC 

JWICS 

Monitor 

40 

CNN 

X 

U 

CABLE  TV 

(BROADCAST 

STATION) 

OCEANIC 
CABLE 

Television 

41 

AFRTS 

X 

U 

MARCH  AFB,  CA 

(BROADCAST 

STATION) 

INTELSAT 
177W 

Television 

42 

UAV/HUD  VIDEO  DOWNLINK 

X 

PLATFORM  BASE 
STATION 

BASE 
STATION 

Monitor 

43 

COMMAND  INFORMATION 

X 

TSC 

JTF 

JTF 

Monitor 

44 

BDA 

X 

X 

s 

JICPAC 

Browser, 
JWICS 

HTML,  Monitor 

45 

PSYCHOLOGICAL 
OPERATIONS  PRODUCTS 

X 

X 

JPOTF 

Television 

46 

PREVENTIVE  MEDICINE 
ORIENTATION  AND  TRAINING 

X 

X 

u 

SVCS, 

COMPONENTS 
(NAVY  EPMU'S) 

NAVY 
EPMU'S 

Monitor 

47 

MEDICAL  SIGNIFICANT 
TRAINING 

X 

X 

u 

SERVICES 
(ECHELON  III 
UNITS,  MEDICAL 
TEACHING 
FACILITIES) 

CONUS 

Monitor+H63 

48 

♦NEO  SUPPORT    *Not  listed  in 
message 

X 

X 

? 

PACOM,  NEO 
CENTERS 

? 

49 

EMERGENCY  ACTION 
MESSAGES  (EAM) 

X 

s 

COMUSKOREA 

SIPRNET 

50 

CINC  FORCE  DIRECTION 
MESSAGES  (FDM) 

X 

s 

USFK 

(CINCUNC/CFC  & 
USFK) 

SIPRNET 

51 

SITUATION  REPORTS 
(SITREPS) 

X 

s 

USFK 

(CINCUNC/CFC  & 
USFK) 

SIPRNET 

52 

FRIENDLY  ORDER  OF  BATTLE 
(FOB)  DATA 

X 

s 

USFK  (CFC  FIELD 
UNITS  & 
SUPPORTING 
ORGS/ELEMENTS) 

SIPRNET 
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53 

ENEMY  ORDER  OF  BATTLE 
(EOB)  DATA 

X 

s 

USFK  (CFC  FIELD 
UNITS  & 
SUPPORTING 
ORGS/ELEMENTS) 

SIPRNET 

54 

INTEGRATED  TARGETING 
ORDER  (ITO) 

X 

S 

USFK 

COMPONENTS 
(COMPONENT 
COMMANDS) 

SIPRNET 

55 

TARGET  NOMINATION  DATA 

X 

S 

USFK  (CINCCFC, 

JICPAC,  TARGET 

NOMINATION 

BOARDS, 

COMPONENT 

COMMANDS) 

SIPRNET 

56 

COLLECTION  MANAGEMENT 
(RFIS) 

X 

S 

USFK  (CP  TANGO, 
OSAN  AND  CAMP 
HUMPHREYS, 
JICPAC) 

SIPRNET 

57 

HUMINT 

X 

S 

USFK  (YONGSAN, 
CP  TANGO,  OSAN, 
HUMPHREYS) 

SIPRNET 

58 

GRAPHIC  INTSUMS  (Intel 
Summaries) 

X 

USFK  (YONGSAN 
IN  ARMISTICE,  CP 
TANGO,  CAMP 
HUMPHREYS, 
OSAN) 

SIPRNET 

ASAS/WARLORD 

59 

INTELLIGENCE  ESTIMATE 
PRODUCTS 

X 

S 

USFK  C2  (CFC  C2) 

SIPRNET 

60 

KOREA  TACTICS,  TECHNIQUES 
AND  PROCEDURES  (KTTP) 

X 

S 

USFK  C2  (CFC  C2) 

SIPRNET 

61 

SIMULATIONS 

X 

S 

USFK,  USCP 
(YONGSAN,  OSAN, 
TAEGU,  CP  TANGO, 
SUWON,  PACOM) 

SIPRNET 

62 

THEATER  MISSILE  DEFENSE 
INTEL  PREPARATION  OF  THE 
BATTLEFIELD  (TMD  IPB) 

X 

S 

USFK  (YONGSAN, 
OSAN,  CP  TANGO, 
HUMPHREYS) 

SIPRNET 

63 

SIGNALS  INTELLIGENCE 
(SIGINT) 

X 

s 

USFK  (YONGSAN, 
OSAN,  CP  TANGO, 
K-50,  HUMPHREYS) 

SIPRNET 

64 

JSTARS 

X 

? 

JSTARS  MGSM 
(WARTIME  MGSM 
LOCATIONS) 

2D  Imagery 

65 

VIDEO  TELECONFERENCE 
(VTC)  BROADCASTS 

X 

7 

USFK 

(CINCCFC/USFK 

AND  VARIOUS 

PENINSULA 

COMMAND 

CENTERS) 

PAC  VTC? 

VTC 

66 

DISTANCE  LEARNING 

X 

X 

U 

USFK  (ALL  U.S. 
MILITARY  POSTS 
AND  CAMPS  IN 
ARMISTICE. 
YONGSAN,  OSAN, 
HUMPHREYS, 
TAEGU,J12 
CHINHAE, 
POHANG,  AS  A 
MIN.) 

? 

VTC,  PASS-K 

67 

NONCOMBATANT 
EVACUATION  OPERATION 
(NEO)  SUPPORT 

X 

X 

s 

USCP,  NEP  CTRS 
(PACOM,  NEO 
CENTERS) 

? 

55 
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